Subscribe to the Non-Human & AI Identity Journal

Why do passkeys not eliminate the need for secrets management?

Because most organisations still rely on service accounts, API keys, shared credentials, and application integrations that do not use passkeys. Those credentials can remain long-lived and broadly scoped, so the organisation still needs inventory, rotation, revocation, and monitoring outside the human login flow.

Why This Matters for Security Teams

Passkeys remove one major source of risk, which is human password reuse and phishing, but they do not replace the broader secret estate that modern organisations depend on. Service accounts, API keys, certificates, OAuth client secrets, and application tokens still exist outside the human login path, which means secrets inventory, rotation, revocation, and monitoring remain essential. NHI Management Group’s Guide to the Secret Sprawl Challenge and the OWASP Non-Human Identity Top 10 both frame this as a lifecycle problem, not just an authentication problem.

The operational mistake is assuming that stronger human authentication automatically reduces secret exposure everywhere else. In reality, passkeys can improve employee sign-in while the organisation still carries long-lived credentials in code, CI/CD, infrastructure, and partner integrations. NHIMG research from The 2024 State of Secrets Management Survey reports that only 44% of organisations are using a dedicated secrets management system, which is a strong signal that many environments still depend on ad hoc controls. In practice, many security teams encounter leaked service credentials only after an integration has already been abused, rather than through intentional lifecycle governance.

How It Works in Practice

Passkeys change how users authenticate, but secrets management still governs what machines, workloads, and integrations use to authenticate and authorise each other. That means teams need separate control paths for human identity and non-human identity. A passkey may satisfy a login prompt, while a workload still needs a certificate, token, or API key to call a downstream service. This is why modern programs pair passkeys with NIST Cybersecurity Framework 2.0 controls for identification, protection, and recovery, plus secret inventory and enforcement mapped to the Ultimate Guide to NHIs – Lifecycle Processes for Managing NHIs.

In practice, the control model usually includes:

  • discovering all secrets in source code, pipelines, vaults, containers, and SaaS integrations
  • tagging each secret to an owner, system, purpose, and expiry date
  • rotating or revoking credentials automatically when they are no longer needed
  • separating human authentication changes from workload credential governance
  • monitoring for use patterns that indicate overbroad scope or stale credentials

Passkeys reduce one class of phishing and password theft, but they do not help when a CI job needs access to an artifact repository, a payment service, or a cloud control plane. That is where the guidance in Ultimate Guide to NHIs – Static vs Dynamic Secrets remains relevant: short-lived, purpose-bound secrets are safer than shared static credentials, but they still need governance. These controls tend to break down in large distributed environments where secrets are embedded in automation and teams lack a reliable ownership map.

Common Variations and Edge Cases

Tighter passkey adoption often increases confidence faster than it reduces risk, requiring organisations to balance user experience gains against the hidden workload of machine credentials. There is no universal standard for treating every non-human credential the same way, so current guidance suggests separating by use case rather than by technology label.

Some teams can reduce secrets exposure by replacing passwords with federated identity, workload identity, or short-lived tokens, but that still leaves legacy integrations, third-party APIs, and break-glass accounts that cannot yet use passkeys. In those cases, the relevant comparison is not passkeys versus secrets management, but passkeys versus unmanaged human credentials and unmanaged machine credentials. The Top 10 NHI Issues resource is useful here because it highlights the recurring failure pattern: organisations secure the front door and leave service accounts, tokens, and certificates exposed elsewhere.

Best practice is evolving toward centralised secret discovery, lifecycle automation, and contextual access enforcement. Until every machine interaction can move to ephemeral identity, secrets management stays necessary even in a passkey-first environment.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-01 Passkeys do not cover non-human secrets inventory and lifecycle risk.
OWASP Agentic AI Top 10 Autonomous workloads often rely on machine credentials beyond human passkeys.
CSA MAESTRO MAESTRO emphasizes securing agent and workload access beyond human auth factors.
NIST CSF 2.0 PR.AA Identity and access governance still applies to secrets and service accounts.
NIST AI RMF AI and automation still need accountable access to non-human credentials.

Inventory all non-human credentials and assign owners before rotating or revoking anything.