How should organisations govern passwords, passkeys, and secrets together?

Why This Matters for Security Teams

Passwords, passkeys, and secrets are often governed by different teams, tools, and policies, but attackers do not care where one control boundary ends and another begins. A password reset, a passkey enrolment, or a leaked API token can all become the same identity failure if ownership, recovery, and revocation are inconsistent. That is why governance should be framed as one identity trust chain, not three separate programmes.

Current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 points in the same direction: treat identity controls as lifecycle problems, not point-in-time authentication events. NHIMG research shows why this matters operationally. In the Guide to the Secret Sprawl Challenge, secret exposure is shown to spread far beyond code repositories, including collaboration and delivery tooling. That means a weak process in one area can undermine the entire trust chain.

In practice, many security teams discover the gap only after a leaked secret, a broken recovery flow, or an orphaned passkey has already created an access path no one can fully trace.

How It Works in Practice

Good governance starts with one policy owner and one shared control model. The organisation should define a single lifecycle for enrolment, proofing, recovery, rotation, and revocation, then apply it consistently to human credentials and runtime secrets. That does not mean the mechanisms are identical. It means the rules for assurance, approval, evidence, and expiry are aligned.

For passwords and passkeys, the key decisions are who can enrol, how recovery is approved, and what assurance is required before replacing a lost factor. For secrets, the same governance lens should answer who may request them, where they may be stored, how long they live, and what event forces invalidation. Best practice is evolving toward short-lived secrets and automated revocation because detection alone is too slow for modern pipelines, especially where secrets can be copied into tickets, chat tools, or build systems. NHIMG’s Ultimate Guide to NHIs - Static vs Dynamic Secrets explains why dynamic secrets reduce exposure, but only when the issuance and expiry policy is actually enforced.

A practical operating model usually includes:

• one inventory of all identity assets, including passwords, passkeys, API keys, certificates, and machine tokens
• shared exception handling for lost devices, emergency access, and break-glass recovery
• rotation rules tied to risk, not calendar convenience
• automatic revocation on termination, compromise, or workflow completion
• logging that links enrolment, use, and revocation events to a common identity record

Implementation teams often map this to central IAM plus a secrets manager, but the real control is policy consistency across both. When a passkey recovery path is looser than password reset or secret rotation, attackers look for the weakest lane and move laterally from there. These controls tend to break down in highly distributed DevOps environments because secrets are created and copied faster than governance teams can inventory them.

Common Variations and Edge Cases

Tighter lifecycle control often increases user friction and operational overhead, so organisations have to balance stronger assurance against faster recovery and developer productivity. That tradeoff becomes most visible in environments with many service accounts, outsourced operations, or emergency support functions.

There is no universal standard for this yet. Some teams keep passkeys under identity governance and secrets under platform engineering, while others unify both under a single privileged access or identity security function. The better model depends on who can actually enforce enrolment quality, approve exceptions, and revoke access across systems. Where the governance model fails is usually not at issuance, but at exception handling and recovery. A forgotten contractor account, an unrotated deployment secret, or a passkey enrolled on an unmanaged device can all become durable access paths if they sit outside the same review process.

High-risk environments should also assume that human and machine identity will increasingly intersect. For example, an operator may use a passkey to approve a deployment that triggers a pipeline secret, so the policy question is not just “is the factor strong?” but “does the entire chain remain valid after the initial login?” For that reason, current guidance suggests treating all three as a single trust graph with separate technical handling but shared governance outcomes. The NHIMG Guide to the Secret Sprawl Challenge and Top 10 NHI Issues both reinforce the same operational lesson: unmanaged exceptions are what turn strong authentication into weak security.

Related resources from NHI Mgmt Group

• How should organisations govern secrets and privileged identities together?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?