Human administrators are the visible half of privileged access. The other half is machine credentials: API keys, database connection strings, service account passwords, certificates and tokens used by applications, pipelines and scripts. They outnumber human privileged accounts in most environments, they rotate less often, and they are the credentials most likely to be sitting in a configuration file or a repository right now.
Secrets management is the control category for that population. This page covers what to specify, how to tell a genuine secrets platform from a vault feature bolted onto something else, and where the commercials mislead. If your requirement is about human administrators rather than machines, start with privileged access management instead.
Establish the scope before you look at products
Secrets live in more places than most organisations expect. Source repositories, CI/CD pipeline variables, container images, Kubernetes manifests, configuration management, scheduled tasks, integration platforms, and the spreadsheets that document them all. A platform decision made before that inventory exists usually solves for one of those places and leaves the rest untouched.
Do a discovery pass first, even a rough one. Scan repositories for committed credentials, list the pipeline variable stores, and ask application owners where their service credentials come from today. The answer determines which integrations matter, and integrations are the whole substance of this category.
The distinction that matters: static storage versus dynamic issuance
Most platforms will store a secret and hand it back to an authorised caller. That is useful, and it is where most organisations start. It leaves the underlying problem intact, because the credential still exists, still has a long life, and is still valid if it leaks.
Dynamic secrets are different. The platform generates a short-lived credential on request, against the target system directly, and it expires by itself. A leaked credential that expires in an hour is a materially smaller problem than one that has been valid since 2019.
Ask specifically which of your target systems support dynamic issuance, and treat the answer as a per-system list rather than a yes or no. Databases, cloud providers and message brokers are commonly supported. Older internal applications frequently are not, and those are usually the ones holding the worst credentials.
What to specify separately
Authentication for machines
How does a workload prove it is entitled to a secret without already holding a secret? This is the bootstrapping problem and it is the single most important technical question in the category. Acceptable answers use platform-attested identity: a cloud instance role, a Kubernetes service account token, a signed pipeline identity. An answer that ends in a long-lived token stored on the host has moved the problem rather than solved it.
Rotation, and what breaks during it
Specify rotation per secret class, and establish what happens to a running application when a credential rotates underneath it. Applications that read a secret once at start-up will not notice a rotation until they restart, which turns a security control into an outage.
Integration coverage against your real stack
Provide the actual list of your CI/CD tooling, cloud platforms, container orchestration, databases and configuration management, and require a per-item response. Integration count is a marketing number. Coverage of your specific stack is the requirement.
Audit and attribution
Every secret access should be attributable to a workload identity, not to a shared service account. Ask what the audit record contains, how long it is retained, and whether it can be exported to your existing logging platform without a custom connector.
Availability and the failure path
If the secrets platform is unavailable, applications that fetch credentials at start-up cannot start. Establish the high availability model, whether caching is supported, and what the documented degraded mode looks like. This platform becomes a runtime dependency of everything that uses it, which is a resilience question as much as a security one.
Where this sits against Australian obligations
The ASD Essential Eight addresses restricting administrative privileges, and machine credentials with standing administrative rights fall squarely inside the intent even though the maturity model is written with human accounts in mind. Use the wording as the basis for requirements and note explicitly where you are extending it to non-human identities, because an assessor will otherwise read the control narrowly.
For APRA-regulated entities, CPS 234 applies proportionality to information assets, and a platform holding every production credential is about as critical as an asset gets. Where the platform is delivered as a service, the provider’s own controls become a due diligence matter, alongside your other vendor and supplier risk management work. Ask for a software bill of materials as well, for the same reason: see SBOM procurement in Australia.
How secrets platforms are priced
Common bases are per secret, per client or workload, per request volume, and per node in a cluster. Per-secret pricing deserves scrutiny, because a thorough discovery pass routinely finds an order of magnitude more secrets than the organisation estimated, and the licence then true-ups against that. Per-request pricing deserves the same scrutiny for the opposite reason: applications that fetch on every operation rather than caching can generate request volumes nobody modelled.
Open-source editions are common in this category and are genuinely capable. The costs that follow are operational rather than licensed: running the cluster, patching it, and holding the expertise. Compare a managed offering against the fully loaded cost of self-hosting, not against the zero on the licence line.
Evidence to request
- A per-system list of which targets support dynamic issuance and which are static storage only.
- The workload authentication methods supported, and confirmation that none require a pre-placed long-lived token.
- Integration coverage against your actual toolchain, item by item.
- Documented behaviour when the platform is unavailable, including caching and degraded mode.
- Rotation behaviour for applications that read credentials only at start-up.
- Australian reference customers who have completed a migration off committed credentials as well as a platform install.
A defensible evaluation sequence
Run discovery before requirements, because the inventory changes what you are buying. Write requirements from the discovery result, weight them, and only then look at pricing.
Prove it on the hardest integration in your estate rather than the reference one. In this category the gap between a vendor’s supported list and your environment is where projects stall, and a proof of value that only covers well-supported targets tells you very little.
Plan the migration as part of the purchase. Buying the platform is the small half; removing credentials from repositories, pipelines and configuration files is the work, and it needs application owners who were not in the procurement. Record the decision and the migration scope together, which the guided vendor evaluation process and the Discover, Evaluate, Engage, Assure method both produce as part of the work.
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 privileged access management for the human half of this problem, identity and access management for the identity layer beneath both, and zero trust network access for how workloads reach the systems these credentials open.
