What Makes a Passkey Different from a Password?
Passkeys are a modern approach to authentication that stores a cryptographic credential on your device.
A verifiable digital credential is only as trustworthy as the key that signed it. For residents, that means being able to present their credential at a service counter, a border crossing, or in an app, and having it accepted without the verifier needing to call back to the issuing agency. For program managers, it means that the infrastructure protecting those keys is one of the more consequential things to get right from the start.
Understanding how signing keys work, how they are protected, and what happens when they change does not require a deep technical background. But it does require some familiarity, because the decisions involved have long-term consequences for how the program operates and for who can be held accountable when changes are needed.
The Chain of Trust
Every verifiable digital credential traces its trustworthiness back to a single point: the issuer's signing key. When a verifier checks a credential, they are ultimately asking whether the key that signed it belongs to an authorized issuer. That chain of trust (from credential to key to issuer) is what makes offline verification possible and what removes the need for a live connection to the issuing agency at every verification event.
This is one of the meaningful differences between verifiable digital credentials and older identity verification approaches. The trust is embedded in the credential itself, carried by the cryptographic signature, rather than dependent on a real-time lookup.
How Key Architecture Works in Practice
Most credential programs use a layered key structure to protect the chain of trust while keeping day-to-day operations manageable.
A root key sits at the top of this structure. It is used only to authorize subordinate keys, often called document signer keys, which handle the actual work of signing credentials. The root key is kept offline, used rarely, and managed under strict controls that typically include formal ceremonies with witnesses and audit trails.
Document signer keys are rotated on a regular schedule (often monthly) to limit the window of exposure. The advantage of this layered approach is containment: if a document signer key needs to be retired or replaced, the root key and the broader trust it anchors remain intact. SpruceID's overview of root keys and signer keys explains how this hierarchy is structured and why the separation matters.
How Signing Keys Are Protected
Signing keys are stored in a hardware security module (HSM), a tamper-resistant device designed specifically to protect cryptographic material. When a credential is signed, the signing request is sent to the HSM, and the signature is returned. The private key stays inside the hardware throughout, even during signing operations.
For government credential programs, FIPS 140-3 Level 3 is the commonly referenced standard for HSM security. It requires tamper-evident physical protection and multi-party authorization for sensitive operations. Specifying HSM storage as a baseline procurement requirement, rather than leaving it as an optional configuration, helps protect the program's trust foundation from the beginning. SpruceID's page on HSMs covers what these devices do and how they are evaluated.
Access controls matter alongside hardware protection. Well-designed issuance systems require explicit authorization to trigger a signing operation, and they log every signing event so that key use remains traceable and auditable over time.
Key Rotation and What It Means for Your Program
Signing keys have a planned lifespan. Rotating them on a regular schedule is standard practice, and it has a concrete operational implication: verifiers need to be able to validate credentials signed with a previous key for as long as those credentials remain in circulation.
A rotation plan that does not account for credential lifetimes can cause valid credentials to fail verification unexpectedly. The rotation schedule and the credential expiry window are best designed together before the program goes live, rather than treated as separate technical decisions. Applying Zero Trust to Government Data Flows covers the broader principle that well-designed government systems plan for components to change over time, and that planning for change from the start tends to produce more resilient programs than retrofitting them later.
Why the Issuing Agency Should Retain Control
One of the more consequential decisions in a credential program is who controls the key infrastructure. The issuing authority, the state agency or government body responsible for the program, is well-served by retaining direct control over its own signing keys and the systems that protect them.
When that control is delegated entirely to a third party, the agency's ability to rotate keys, respond to a security event, or move to a different platform depends on the vendor's cooperation. It also means the trust anchor of the entire credential program sits outside the agency's direct authority. Keeping control of key infrastructure is a governance principle with practical consequences for residents and program accountability, not just a procurement preference.
The credential lifecycle framing is useful here: key management underpins the issuance stage, but its effects carry through to every subsequent stage, including active use, revocation, and renewal. Getting it right early makes every later stage more straightforward to manage.
A Starting Point
Key management decisions are easier to get right during program design than after credentials are in the field. A few areas worth addressing early include key rotation authority and documentation, HSM requirements and assurance level, and whether the agency retains direct control over its signing key infrastructure. SpruceID has helped agencies work through these requirements at every stage of credential program design. If you are interested in learning more, get in touch.
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.
