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

At a glance

What this is: Singpass’s new passkey model keeps credentials device-bound inside the app and away from synced cloud wallets.

Why it matters: That matters because IAM teams should treat credential custody, revocation, and federation boundaries differently when a national identity layer owns the authenticator itself.

By the numbers:

• Singpass has more than 4.5 million monthly active app users running over 41 million transactions a month across roughly 2,700 government and private sector services.
• 2025, hing was the second most common scam type in Singapore in 2025, with reported losses of around S$39.9 million, and several of those scams used fake Singpass pages or QR flows.

👉 Read Authsignal's analysis of Singpass device-bound passkeys and digital credentials

Context

Singpass is moving a national identity workflow from password and SMS dependence toward device-bound passkeys, and that changes the control point for authentication. The key issue is not the passkey label itself, but whether the credential lives inside a synced consumer wallet or remains under issuer-controlled custody inside the app.

For identity teams, the governance question is how control shifts when the authenticator is no longer a portable personal credential. That affects recovery, revocation, proof of device possession, and how the relying party trusts the upstream identity provider in a federated flow.

The article is an interesting case because it applies issuer-managed passkeys to a national digital identity system rather than a typical consumer login. That makes the trade-off unusually visible: stronger control and narrower recovery paths in exchange for less portability.

Key questions

Q: How should security teams decide where to use syncable passkeys versus device-bound keys?

A: Use syncable passkeys where usability and scale matter most, but keep device-bound keys for privileged access, regulated workflows, and any application where the organisation must preserve a stronger device-to-credential binding. The decision should be based on assurance requirements, not user preference alone. If the workflow tolerates credential portability, syncable passkeys are reasonable. If it does not, hardware binding should stay mandatory.

Q: Why do passkeys reduce phishing risk compared with passwords?

A: Passkeys are bound to the original website and use cryptographic proof instead of a reusable secret. That means a fake site cannot harvest a password and replay it later. The phishing benefit is real, but it only holds if the organisation also limits weak fallback methods that attackers can abuse instead.

Q: What do teams get wrong about passkey security?

A: Teams often assume passkeys are either perfect or too risky to adopt. The better view is that they remove the reusable secret that makes phishing and replay so effective, while leaving a smaller set of governance questions around recovery, sharing, and sync protection. The control is stronger, but policy still matters.

Q: Who should control passkey policy in a federated login model?

A: The upstream identity provider should control passkey policy when it is the party issuing the assurance used by relying services. Downstream applications can consume that assurance, but they should not pretend they own the ceremony if they do not. Accountability sits where the authenticator is governed.

Technical breakdown

Device-bound passkeys and WebAuthn custody

A device-bound passkey uses standard WebAuthn: a public-private key pair is created, the private key stays on the device, and the public key is registered with the identity provider. The important difference from synced passkeys is custody. With sync, recovery often depends on a cloud account and a replicated credential store. With device binding, the credential is non-exportable and the issuer can tie revocation to a specific device instance. That makes the authenticator closer to a managed identity artefact than a portable consumer convenience.

Practical implication: Practitioners should distinguish between synced and device-bound custody when writing assurance and recovery policies.

Why domain binding and proximity checks reduce phishing

Passkeys resist phishing because the authenticator signs only for the legitimate relying domain, so a lookalike site cannot harvest a reusable secret. In Singpass’s model, a second device login also adds Bluetooth proximity verification, which helps prevent remote relay attacks where a victim is tricked into authorising someone else’s session. This is stronger than QR or OTP flows because the attacker cannot easily separate the user from the transaction context and replay the result elsewhere.

Practical implication: Teams should treat phishing resistance as a property of ceremony design, not just of the credential format.

Federation, relying parties, and attestation control

Singpass acts as the passkey verifier and then federates to downstream services through OpenID Connect. That means relying parties do not directly manage the WebAuthn ceremony, but they inherit the identity assertion from the upstream provider. The article also highlights AAGUID-based restriction, where an app-based authenticator can present a stable identifier and attestation signal. That is not generally available in cloud-synced consumer passkeys, which limits how tightly a relying party can pin accepted authenticators.

Practical implication: Federated relying parties should decide whether control lives at the IdP layer or at the authenticator policy layer before they scale passkey use.

Threat narrative

Attacker objective: The attacker aims to obtain authenticated access to the victim’s Singpass-linked session and use that trust to reach downstream services.

1. Entry occurs through phishing and QR-based lures that capture a user into authorising the wrong session rather than disclosing a password. Escalation happens when a remote attacker reuses that approval path to complete login from a separate device or location. Impact is account takeover through a trusted identity channel that the victim believed was authentic.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Device-bound passkeys create a custody model, not just an authentication upgrade. The real shift is that the issuer keeps the credential tied to one device and one recovery path instead of distributing copies through a consumer sync fabric. That changes who can revoke, who can recover, and who can assert control over the authenticator lifecycle. For identity governance, this is a custody decision with policy consequences, not a UX choice.

Sync convenience and issuer control solve different problems. Synced passkeys optimise user recovery, but they also move trust into the cloud account that restores them. Device-bound credentials reduce that dependency and make revocation more deterministic. The result is a cleaner accountability model for national identity, but it also raises the operational cost of replacement and support.

Federation does not remove authenticator governance. Even when downstream relying parties use OpenID Connect, the control boundary still begins at the upstream identity provider and its authenticator policy. This is where the named concept of credential custody boundary matters: once the issuer owns the boundary, the relying party inherits assurance rather than building it directly. Practitioners should treat that as a design constraint in every federated access model.

National identity programmes are beginning to separate authentication from portable credential ownership. That matters because the same logic will influence regulated consumer identity, workforce access, and eventually some machine identity patterns. The more sensitive the relying party, the more attractive issuer-managed, device-bound credentials become, especially when phishing and replay are already costly.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
• Forward look: For broader lifecycle guidance, NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding controls should be structured.

What this signals

Credential custody is becoming a first-class governance decision. As more identity systems shift from synced credentials to issuer-controlled, device-bound models, teams need to decide where recovery, revocation, and attestation live in the stack. That decision will increasingly determine whether the organisation can enforce assurance consistently across human identity, NHI, and delegated federation.

With 88.5% of organisations saying their non-human IAM practices lag human IAM, per The 2024 Non-Human Identity Security Report, the underlying problem is not limited to machine identity. It is the broader tendency to outsource control assumptions to whatever login experience ships first, then treat the governance model as an afterthought.

The next phase of passkey adoption will likely split into two patterns: consumer convenience for low-friction use cases and issuer-managed custody for regulated identity. That split will force IAM and IGA teams to document where assurance is created, where it is inherited, and where it can be revoked without relying on user-owned sync layers.

For practitioners

• Map credential custody boundaries Document whether passkeys are synced, device-bound, or issuer-managed, and tie each model to its recovery and revocation workflow. Treat the custody model as a control decision, not an implementation detail.
• Review federation assumptions at the IdP layer For downstream applications, confirm whether authentication assurance is enforced upstream in the identity provider or locally at the application. That determines where policy, assurance, and revocation decisions actually sit.
• Separate phishing resistance from portability Do not assume that every passkey deployment has the same assurance profile. Compare domain binding, attestation, and recovery paths before approving a rollout for sensitive populations.
• Define device loss procedures before rollout If a credential is device-bound, replacement and deactivation must be explicit in operations. Make sure help desk, in-person service, and account recovery steps are written before the first production release.

Key takeaways

• Singpass’s passkey design is really a custody decision, because the issuer keeps control of a device-bound credential rather than syncing it through a consumer wallet.
• The security gain comes from tighter phishing resistance and cleaner revocation, but the trade-off is reduced portability and more explicit recovery operations.
• Identity teams should treat federation, attestation, and recovery as separate control layers, not as side effects of adopting passkeys.

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.
• 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.

What's in the full article

Authsignal's full blog post covers the operational detail this post intentionally leaves for the source:

• How Singpass implements device-bound passkeys inside the app on iOS and why that differs from synced wallets
• The WebAuthn ceremony details, including RP binding, AAGUID policy, and attestation handling
• The comparison between passkeys and digital credentials, including when each model fits national identity
• Platform-level constraints on third-party credential providers and what that means for issuer-managed authentication

👉 Authsignal's full post covers the WebAuthn mechanics, federation model, and digital credential direction in more detail.

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.