Device-bound passkeys change identity control in Singapore’s Singpass

At a glance

What this is: Singpass is moving to device-bound passkeys in its app, making the issuer, not a cloud sync layer, the control point for credential locality, recovery, and revocation.

Why it matters: For IAM teams, the case shows how passkey architecture changes governance assumptions around recovery, device loss, and issuer control, which matters whenever a trusted identity layer must enforce lifecycle and phishing resistance.

Context

Singapore’s Singpass is adding passkeys as a new authentication method for a national identity app that already supports QR login, face verification, and SMS OTP. The key governance question is not whether passkeys work, but who controls the credential lifecycle when the identity service itself needs stronger assurance.

In this design, the passkey is device-bound and stays inside the Singpass app instead of syncing through a consumer cloud wallet. That shifts recovery, revocation, and accountability toward the issuer, which is the central issue for identity teams evaluating whether passkeys should be treated as user convenience or as governed credentials.

Key questions

Q: Should organisations use synced or device-bound passkeys for privileged access?

A: For privileged access, device-bound passkeys are the better default because they keep the private key on a single device and narrow the portability of the credential. Synced passkeys are more convenient, but that convenience comes with different recovery and propagation assumptions. Privileged roles need the tighter assurance boundary.

Q: Why do synced passkeys create governance problems for corporate accounts?

A: Synced passkeys can escape the organisation’s control when they land in a personal cloud account that IT cannot inspect or revoke. If that personal account is compromised, every synced credential inside it is exposed. In B2B, that shifts trust from corporate policy to a consumer platform, which weakens lifecycle control, offboarding, and incident response for access to production systems.

Q: What breaks when a passkey model assumes automatic cross-device recovery?

A: Recovery becomes a hidden trust dependency on the sync account and its ecosystem, which can undermine issuer revocation and complicate device loss handling. In high-assurance identity, that breaks the expectation that the issuer can cleanly retire one credential and replace it with another without extending trust to a separate cloud layer.

Q: How should identity teams evaluate passkeys in a national or regulated ID system?

A: Evaluate whether the passkey strengthens issuer governance over authentication, recovery, and revocation, not just whether it removes passwords. In a national ID system, the right question is whether the credential stays under the issuer’s control enough to support strong assurance, clean offboarding, and reliable session binding.

Technical breakdown

How device-bound WebAuthn changes passkey custody

Device-bound passkeys use the standard WebAuthn model, but the private key never leaves the device and is not replicated through a sync fabric. The issuer registers the public key and later verifies a signed challenge from the same bound credential. That differs from synced passkeys, where recovery depends on a broader cloud account and the credential may exist across multiple devices. In a national identity context, that distinction changes custody, locality, and the revocation story. It also gives the issuer a clearer picture of which device is presenting the credential, instead of relying on a shared sync ecosystem.

Practical implication: Treat device-bound passkeys as governed credentials with explicit lifecycle ownership, not as a generic password replacement.

Why phishing resistance improves when the credential is issuer-bound

Passkeys reduce phishing because the authenticator signs only for the real relying domain, not a lookalike page. Singpass also adds proximity checks for second-device use, which makes remote relay attacks harder than older QR-based flows. The important point is that phishing resistance here is not just a cryptographic property. It is also a consequence of narrowing where the credential can exist and which session context can trigger it. For national or regulated identity systems, that combination matters more than simple login convenience because the adversary is often trying to hijack an authenticated session rather than steal a reusable secret.

Practical implication: Map phishing resistance to session binding and issuer control, not only to the presence of passkeys.

Why sync passkeys and device-bound passkeys are different governance models

Synced passkeys optimise recovery and user convenience, but they move trust into the security of the sync account and its cloud ecosystem. Device-bound passkeys do the opposite: they reduce portability in exchange for tighter control over revocation and a cleaner one-person, one-active-credential model. That makes them attractive where the issuer must retain strong control over enrollment, deactivation, and device replacement. The trade-off is operational rather than theoretical. If a programme cannot support re-enrolment flows, help-desk handling, or replacement-device recovery, device-bound credentials become hard to run at scale.

Practical implication: Decide whether your programme optimises for cross-device convenience or for issuer-controlled credential locality before you standardise passkey policy.

Threat narrative

Attacker objective: The attacker wants to hijack a valid Singpass-authenticated session without needing the underlying credential to move off the user’s device.

1. Entry occurs when a user authenticates through a phishing page or a QR relay flow that imitates the real service and tricks the victim into approving access.
2. Credential abuse is prevented when the passkey is domain-bound and device-bound, because the attacker cannot extract a reusable secret or replay it from a remote system.
3. Impact is limited by keeping the credential inside the issuer-managed app, where revocation follows device replacement and the attacker cannot inherit a synced copy.

Breaches seen in the wild

• Twilio 0ktapus breach 2022: SMS phishing of employees exposed 209 Twilio customers and 1,900 Signal users, part of the 0ktapus campaign against 130+ firms.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Device-bound passkeys are a control model, not just an authentication method: Singpass is not simply adding another login option. It is choosing a credential custody model where the issuer retains tighter control over issuance, locality, and revocation. That matters because identity governance is ultimately about who can bind, move, and retire credentials, not only how users unlock them. For national and regulated identity systems, the practical conclusion is that passkey design choices are governance choices.

Sync convenience creates credential lifecycle ambiguity: Synced passkeys distribute trust across the user’s cloud account and multiple devices, which is convenient but weakens the issuer’s ability to reason about one active credential per person. Device-bound passkeys collapse that ambiguity by keeping the authenticator tied to a single device and a single issuer-defined lifecycle. The implication is that some identity programmes should reject portability when accountability depends on a narrow recovery path.

Issuer-controlled passkeys narrow the phishing surface, but only because the trust boundary is smaller: The protection comes from domain binding, proximity checks, and app-level custody working together. That combination is stronger than simply saying passkeys are phish-resistant. For practitioners, the lesson is that credential architecture and threat model must be designed together, especially where government identity, federation, and downstream relying parties are all in play.

Singpass exposes a portability ceiling for the passkey ecosystem: Not every programme should try to build its own device-bound credential manager. A national identity layer can justify that design because it owns the user relationship and the revocation path, but most services cannot. The field-level implication is that passkeys will likely split into two governance patterns: consumer portability and issuer-managed custody. Teams should stop treating those as interchangeable.

Device-bound credential locality is the better mental model for high-assurance identity: The useful concept here is not just device binding, but credential locality under issuer governance. That term captures why national identity systems, regulated access, and high-assurance digital services increasingly care about where the private key lives and who can move it. Practitioners should evaluate passkeys on lifecycle control first and user convenience second.

What this signals

Device-bound credential locality: National identity programmes are likely to keep favoring credentials that remain under issuer control when revocation, re-enrolment, and provenance all matter. That preference is not about resisting convenience. It is about preserving a manageable lifecycle when the identity service itself is the trust anchor.

Passkey policy should now be written as a custody decision, not an authentication feature decision. Teams that treat synced and device-bound passkeys as equivalent will miss the operational difference between portability and issuer-managed control.

For identity architects, the Singpass pattern shows that high-assurance login design is converging with lifecycle governance. The next design review question is not simply whether passkeys are deployed, but who can move, replace, and retire them when risk changes.

For practitioners

• Assess credential custody assumptions Review whether your current passkey policy assumes cross-device recovery, cloud sync, or issuer-controlled re-enrolment, then map that assumption to your risk appetite and help-desk model.
• Separate phishing resistance from recovery design Document which controls make the login phishing-resistant and which controls govern device loss, replacement, and revocation, because those are different decisions even when both use passkeys.
• Define who owns credential revocation Specify whether the issuer, the user, or a sync provider can invalidate a credential after device replacement or compromise, and make that ownership explicit in policy.
• Decide when a device-bound model is justified Use device-bound credentials only where issuer locality, tighter revocation, or high-assurance identity outweigh the operational cost of re-enrolment.

Key takeaways

• Device-bound passkeys shift control from a consumer sync layer back to the issuer, which changes how identity teams think about recovery and revocation.
• The main benefit is not convenience but tighter credential custody, cleaner deactivation, and stronger resistance to phishing and relay-style abuse.
• Practitioners should decide whether their programme needs portability or issuer-managed locality before standardising on a passkey model.

Key terms

• Device-Bound Passkey: A device-bound passkey is a FIDO credential tied to one physical device and generally stored in hardware-backed secure components. The value for enterprise security is lifecycle control, because the credential is easier to inventory, constrain, and revoke without relying on cloud sync paths.
• Credential custody boundary: The point at which control over an authenticator shifts from the user or platform to the issuing identity system. For device-bound credentials, that boundary determines who can revoke, replace, attest, and recover access, making it a governance issue rather than a storage detail.
• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
• Federated relying party: A downstream service that accepts an identity assertion from an upstream provider instead of running the authentication ceremony itself. The relying party depends on the provider’s assurance model, so policy, revocation, and authenticator governance must be understood at the federation boundary.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.