Privileged access is the smallest population of accounts in an organisation and the largest share of its risk. A domain administrator, a cloud root account, a service account with standing database rights: each one collapses the distance between an attacker landing on a workstation and an attacker owning the environment. Most Australian organisations already know this. Fewer have bought a privileged access management platform in a way that survives contact with their own operations.
This page sets out what to specify, what evidence to ask for, and where privileged access management projects usually run into trouble commercially. It assumes you have identity management in place already. If you do not, start with identity and access management and come back to this once ordinary user identity is under control.
What privileged access management covers, and what it does not
PAM is often sold as a single product. In practice it is four or five separate capabilities that vendors bundle differently, which is the root cause of most failed comparisons. One vendor’s platform includes secrets management for machine identities; another treats that as a separate SKU. One includes session recording at every tier; another charges for it above a threshold.
PAM is not identity governance. It does not decide who should have access in the first place, review entitlements on a cycle, or handle joiner, mover and leaver processes. If your requirement is really “we do not know who has access to what”, that is an identity governance requirement and a PAM platform will not answer it.
Why this is a procurement problem as well as a security one
Privileged access touches every system that matters, which means a PAM rollout depends on teams who do not report to whoever bought it. Database administrators, network engineers, application owners and third-party support partners all have to change how they connect. A platform that is technically excellent and operationally resented does not get adopted, and an unadopted PAM platform is worse than none because it creates a documented control that is not actually operating.
That makes two things procurement questions rather than technical ones. First, how much change the platform imposes on the people who use privileged accounts daily. Second, what the vendor is contractually committed to during rollout, as opposed to what the account team says during evaluation.
The capabilities to specify separately
Credential vaulting and rotation
The baseline: privileged credentials are held in a vault, checked out under policy, and rotated automatically. The questions that separate vendors are how rotation behaves when a target system is unreachable, whether rotation can be scheduled per system class, and what happens to an in-flight session when a credential rotates underneath it.
Session isolation and recording
Session isolation means the privileged credential is never exposed to the endpoint the administrator is sitting at. Recording means the session is captured for later review. Ask whether recording is full video, keystroke and command logging, or metadata only, and ask what the storage growth looks like at your session volume. Recording is where PAM storage costs escalate quietly.
Just-in-time elevation
Standing privilege is the thing you are trying to remove. Just-in-time elevation grants rights for a bounded window and removes them afterwards. Test the approval path: if elevation requires a ticket and an approver who is asleep, engineers will keep a standing account somewhere as a workaround, and you will have bought a control that people route around.
Secrets management for machine identities
Human administrators are the visible problem. Service accounts, CI/CD pipelines, scripts and application-to-application credentials usually outnumber them and rotate less often. Establish early whether machine secrets are in scope, because it changes both the platform shortlist and the price materially.
Break-glass and recovery
Ask what happens when the PAM platform itself is unavailable. Every vendor has a break-glass answer. The useful question is how that answer is tested, how the emergency credentials are protected, and whether using them raises an alert. A PAM platform that becomes a single point of failure for administrative access has moved risk rather than reduced it.
What Australian obligations actually require
Restricting administrative privileges is one of the eight mitigation strategies in the ASD Essential Eight, and the maturity model sets out escalating expectations: validating requests, limiting standing access, and logging privileged activity. If your organisation reports against an Essential Eight maturity level, the wording of that model is the most useful requirements source you have, because it is what an assessor will measure you against later.
For APRA-regulated entities, CPS 234 requires information security controls proportionate to the criticality of the asset, and privileged access to critical systems sits at the top of that scale. Neither instrument names a product category. Both create an evidence obligation, which is why the recording and reporting capabilities above matter more than they first appear.
Where a third party holds privileged access to your environment, the obligation extends to them. That is a supplier assurance question as much as a technical one, and it belongs in the same assessment as your other vendor and supplier risk management work.
How PAM vendors price, and where the cost lands
Pricing models in this category are unusually varied, which makes like-for-like comparison hard unless you force it. The common bases are per privileged user, per managed target system, per concurrent session, and per vault. Some vendors combine two. A shortlist priced on different bases cannot be compared on licence cost alone.
Three costs are routinely underestimated. Session recording storage, which grows with usage rather than with headcount. Connector or integration work for systems that are not on the vendor’s supported list. And the professional services required to onboard target systems, which is often quoted for an initial tranche and not for the long tail that follows.
Normalise the comparison by building a three-year model on your own numbers: your privileged user count, your target system count, your expected session volume, and a realistic onboarding schedule. Ask each vendor to price that model rather than accepting their standard bundle.
Evidence to request before shortlisting
- A supported-systems list, checked against your actual estate rather than a representative sample.
- Storage sizing for session recording at your session volume, in writing.
- The break-glass procedure, and evidence it has been tested.
- Reference customers of comparable size in Australia, and specifically ones who have completed rollout rather than started it.
- A software bill of materials, which matters here because the platform holds your highest-value credentials. See SBOM procurement in Australia.
- Documented behaviour when the platform is unavailable, degraded, or mid-upgrade.
A defensible evaluation sequence
Write requirements before you speak to vendors, and write them from the Essential Eight maturity wording plus your own operational constraints. Weight them before you see pricing. Score against evidence rather than demonstration, because a scripted demo will show you the happy path on every platform in the category.
Run a proof of value on your two hardest target systems, not your easiest. The systems that are awkward to onboard are the ones that will determine whether the rollout finishes. If a vendor declines to include those in a trial, that is itself a finding worth recording.
Document the reasoning behind the final selection while the evaluation is fresh. That record is what makes the decision defensible in a board paper, an audit, or a regulatory review, and it is the part organisations most often skip. The guided vendor evaluation process and the Discover, Evaluate, Engage, Assure method both exist to produce that record as a by-product rather than as an afterthought.
Sources
- Essential Eight Maturity Model, Australian Signals Directorate.
- Essential Eight Explained, Australian Signals Directorate.
- CPS 234 Information Security, Australian Prudential Regulation Authority.
- Cybersecurity Framework, National Institute of Standards and Technology.
Where to read more
See identity and access management for the layer beneath this, Essential Eight procurement and provider evaluation for the wider control set, and zero trust network access for how privileged sessions reach systems in the first place.
Also relevant: vendor remote access into plant environments, and secrets management for machine identities.
