Supplemental Security Keys

Expanded Definition

Supplemental Security Keys are additional authentication signals layered onto passkey use so an organisation can judge not just whether a credential was presented, but whether the device behind it is known, trusted, and suitable for the action being attempted. The term is still evolving across vendors, so implementation details vary.

They sit alongside passkeys rather than replacing them. A passkey answers the core authentication question, while supplemental signals add context such as device trust, enrollment state, and assurance level. That boundary matters because organisations sometimes treat any extra signal as full device attestation, even when it only improves confidence rather than proving strong hardware-backed identity.

For background on how passkeys fit into broader digital identity assurance, the NIST passkeys glossary entry is useful because it clarifies the baseline authentication model that these supplemental signals extend.

Examples and Use Cases

In practice, supplemental security keys appear where one login factor is not enough to decide whether a session should proceed with full trust. They are most useful when risk-sensitive actions need a stronger check than ordinary sign-in.

• A workforce portal allows a passkey for everyday access, then asks for a supplemental signal before approving payroll changes or export-sensitive data access.
• A help desk workflow uses the signal to distinguish an employee on a managed laptop from the same user authenticating on an unmanaged or newly enrolled device.
• An identity platform uses device trust context to step up authentication when a sign-in originates from a location, browser, or device profile that differs from the user’s normal pattern.
• A customer-facing application uses the extra signal to reduce account takeover risk without forcing every user into a repeated full reauthentication flow.

The main trade-off is assurance versus friction. More context can improve decision quality, but only if the organisation can reliably collect, interpret, and maintain that context without locking out legitimate users.

Security Implications

When supplemental security keys are misunderstood, organisations may overestimate how much assurance they have and allow high-value actions based on weak or stale device context. The failure is often not the passkey itself, but the assumption that a contextual signal is equivalent to strong device proof.

That creates several problems: attackers who obtain a valid passkey can still benefit if the supplemental signal is easy to spoof, poorly enrolled, or not revalidated when device posture changes; risky sessions may be treated as ordinary ones; and fraud or account takeover workflows may be missed because the control only informs the login screen, not downstream authorisation decisions. In machine-identity programs, a similar pattern appears when organisations rely on extra context while losing visibility into the actual trust relationship. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which is a reminder that assurance collapses when the underlying identity signal is incomplete.

A common practitioner reality is that the quality of the signal matters more than the label. If device trust cannot be independently verified, a “supplemental” key may reduce risk at the margin but still leave a meaningful gap in session assurance.

Domain and Governance Relevance

Supplemental Security Keys matter wherever organisations are trying to move from simple authentication to risk-based access decisions. They are especially relevant in identity governance because they sit between user intent and policy enforcement, shaping whether a request is treated as low risk, step-up worthy, or unsuitable for sensitive action.

For NHI and agentic environments, the same logic shows up in a different form: machine identities also need context about trust, device, workload, or execution environment before sensitive operations are allowed. That does not make supplemental security keys an NHI control by themselves, but it does make them conceptually relevant to any programme that relies on strong assurance before granting privileged or automated access.

Practically, this term belongs in conversations about authentication assurance, device trust, and conditional access design, not just user convenience. It is most valuable when governance teams need a clearer boundary between proving who or what authenticated and proving that the authenticating endpoint is appropriate for the requested action.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• What is the difference between OAuth tokens and API keys from a security perspective?
• How should security teams govern signing keys in container pipelines?
• How should security teams replace static SSH keys with short-lived access controls?