Most people have had the same experience: you create an account, invent a password, forget it within a week, reset it, and then do it all again. It's tedious and one of the most significant security vulnerabilities in modern digital services.
Passkeys are a newer approach to proving who you are online, one that removes the shared secret entirely. Understanding what they are and why they're structured differently helps explain why more platforms, including government digital services, are moving in this direction.
A password works by creating a shared secret between you and a service. You know it, and the service stores it. When you log in, you send your password to the server, the server checks it against what it has on file, and if they match, you're in.
The challenge is that this model requires the service to store sensitive data, and storage carries risk. Data breaches, phishing attacks, and credential stuffing (in which stolen passwords from one site are used on others) are all downstream consequences of the password model. When a service is compromised, every user's password becomes a potential entry point somewhere else. And because people reuse passwords across services, a single breach can cascade far beyond the site where it happened.
Password complexity rules and two-factor authentication help, but they add friction without solving the root problem: a shared secret that must be stored somewhere it can be stolen.
A passkey uses public-key cryptography instead of a shared secret. When you create a passkey for a service, your device generates two mathematically linked keys: a private key, which stays on your device and never leaves it, and a public key, which is sent to and stored by the service.
When you authenticate, the service sends a challenge (a unique piece of data) to your device. Your device signs the challenge with the private key and sends the signed response back. The service uses the public key to verify the signature. If it checks out, you're in.
Nothing sensitive is transmitted. The private key never moves. The service stores only your public key, which is mathematically useless without the private key locked on your device. Even if the service's database is breached, there is nothing there that can be used to impersonate you. And because each passkey is unique to a single service, there's no credential that can be reused across sites.
This is a meaningful structural shift. The security model no longer depends on a secret that has to be stored somewhere; it depends on a key that never leaves your possession.
With a password, you prove your identity by knowing something. With a passkey, you prove your identity by possessing a device and by unlocking it, typically with a biometric or PIN.
When you use a passkey on your phone, unlocking it with Face ID or a fingerprint isn't being sent to the service. It's being processed locally, on your device, to release the private key for signing. The service never sees your biometric data. It only sees a cryptographic signature that proves your device, secured by you, generated it.
This is the same underlying principle behind device binding in verifiable digital credentials, the idea that a credential's trustworthiness is strengthened when it's tied to a specific device and can't simply be copied or replayed elsewhere.
One of the most important properties of passkeys is that they're origin-bound. A passkey is registered to a specific domain, say, agency.gov. When your device goes to sign a challenge, it checks that the request is actually coming from that domain. If a phishing site tries to impersonate agency.gov, the passkey simply won't work there.
This is a significant departure from passwords, which have no built-in awareness of where they're being used. A well-crafted phishing page looks identical to the real thing, and users routinely enter their credentials without noticing. Passkeys eliminate that attack surface by design.
This kind of design-level protection, building the security property into the mechanism itself rather than relying on the user to catch the threat, is consistent with privacy-preserving design in public services, where the goal is to make the right behavior the default, not the exception.
Passkeys aren't credentials in the same sense as verifiable digital credentials or mobile driver's licenses. They authenticate you to a service, they don't carry verified claims about who you are. But they operate on the same cryptographic foundation.
In practice, passkeys play a specific role in digital identity ecosystems: they secure access to the wallet. When a resident enrolls in a state digital identity program or sets up a wallet to hold a mobile driver's license, passkeys can protect the account system or wallet application that controls those credentials. The cryptographic protections built into the credential itself are only as strong as the authentication layer that controls who can present it. Passkeys close that gap.
The move toward passkeys reflects a broader shift in how trust is being built into digital systems, away from shared secrets and toward device-bound, cryptographically verifiable proofs. As government services adopt verifiable credentials for things like benefits access, program enrollment, and identity proofing, the authentication layer matters just as much as the credential layer. How Do Verifiable Digital Credentials Work? A Non-Technical Explanation is a good companion read if you're thinking about the broader question of how identity is proved online and where passkeys fit into that picture.
Unlike hardware security keys, most passkeys can synchronize across your devices through your platform's cloud account. A passkey created on an iPhone is automatically available on an iPad and Mac through iCloud Keychain. Google synchronizes passkeys across Android devices and Chrome. This means getting a new phone doesn't require re-registering with every service - your passkeys travel with your platform account.
That said, passkeys are generally tied to their ecosystem. Moving from iPhone to Android, for example, typically requires re-registering passkeys with each service, because the synchronized credentials don't transfer across platforms. For most people, this is a manageable one-time step, but organizations deploying passkeys at scale should plan for it and build clear recovery flows for users who lose access to both their device and their platform account.
Passkeys are now supported by all major platforms and browsers, and adoption by government services is growing. Apple, Google, and Microsoft have all implemented passkey support in their operating systems and browsers. The FIDO/WebAuthn standard that underlies them was developed collaboratively by the FIDO Alliance and the W3C. Because passkeys combine something you have (your device) with something you are or know (a biometric or PIN) in a single authentication gesture, they can satisfy multi-factor authentication requirements, and NIST's guidance on digital identity (SP 800-63) increasingly reflects authentication models that align with these principles.
The underlying point is simple: a system that never has to store your secret is more resilient than one that does. Passkeys aren't a perfect solution to every authentication problem, but they address the structural vulnerabilities that passwords carry by design.
Understanding that distinction, shared secret versus device-bound key, is the starting point for thinking clearly about authentication in modern digital services.
Building digital services that scale take the right foundation.
About SpruceID: SpruceID builds digital trust infrastructure for government. We help states and cities modernize identity, security, and service delivery — from digital wallets and SSO to fraud prevention and workflow optimization. Our standards-based technology and public-sector expertise ensure every project advances a more secure, interoperable, and citizen-centric digital future.
