TL;DR: Passkeys replace passwords with cryptographic authentication tied to a user’s device and are positioned by Cerby for shared-app access, admin visibility, and reduced password overhead, according to Cerby and the FIDO Alliance. Passwordless controls improve sign-in security, but they also force IAM teams to rethink how shared accounts, revocation, and access logging are governed.
At a glance
What this is: Cerby describes how passkeys change shared-app authentication by replacing passwords with device-bound cryptographic sign-in and revocable administrative control.
Why it matters: IAM and IGA teams need to account for passwordless shared access because authentication strength alone does not resolve ownership, logging, or offboarding issues.
Context
Passkeys are a passwordless authentication method that uses public-key cryptography, with the private key kept on the user’s device and the public key validated by the app or service. In shared-app environments, that changes the control point from reusable passwords to device-mediated approval, which is a meaningful shift for identity governance.
Cerby’s framing matters because shared accounts have always been awkward for IAM: they are used by multiple people, yet they still need assignment, logging, and revocation discipline. Passkeys can reduce password exposure, but they do not remove the need to decide who can use the account, how access is audited, and how offboarding works when the business relationship changes.
For practitioners, the key question is not whether passkeys are more secure than passwords in isolation. It is whether the surrounding governance model can keep pace when authentication becomes stronger but account ownership remains shared.
Key questions
Q: What breaks when shared accounts move to passkeys without lifecycle controls?
A: The biggest failure is false confidence. Teams may assume that passwordless login has solved the problem, while the account remains shared, overexposed, or difficult to revoke. That creates a governance gap where access remains active longer than intended and audit evidence is incomplete.
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: How do teams know if passwordless shared access is actually governed?
A: Look for evidence that shared accounts have named owners, enrolment records, audit logs, and a removal process when access is no longer needed. If those controls are missing, passkeys have improved authentication but not governance. The programme is working when revocation and review are as visible as sign-in success.
Q: How should IAM teams handle shared passwords and shared credentials?
A: IAM teams should treat shared passwords as a control exception that increases risk and weakens accountability. If shared access is unavoidable, it needs a documented owner, tight privilege boundaries, frequent review, and a clear plan to eliminate it. The safer default is to move to individual accountability or privileged session controls.
Technical breakdown
How passkeys work in shared-app authentication
Passkeys replace shared secrets with asymmetric cryptography. The app receives a public key, while the private key stays on the device and is released only after local user verification such as Face ID, Touch ID, a PIN, or a hardware security key. Because the private key never leaves the device and the authentication challenge is domain-bound, phishing and replay attacks lose the reusable credential they depend on. In shared-app scenarios, that improves sign-in security, but it also means access is tied to the device and the approved user action rather than a password that can be handed around.
Practical implication: treat passkeys as an authentication control, not as a complete shared-access governance model.
Why revocation and logging matter more after passwordless sign-in
When a password disappears, the governance burden shifts to assignment and revocation. If multiple people can access the same business app through a passkey workflow, the organisation still needs to know who enrolled the credential, who can use it, and how usage is logged. The technical risk is not credential reuse in the old sense, but lingering authorised access that is hard to attribute cleanly if lifecycle controls are weak. That is why visibility, auditability, and removal workflows become more important when shared accounts move to passwordless access.
Practical implication: align passkey enrolment, audit logs, and removal workflows with account ownership and offboarding controls.
How hybrid password plus passkey management changes operations
Cerby also describes hybrid management on iOS, where passkeys can be assigned to existing stored credentials. That creates a transitional state in which an account may support both older password-based access and newer passwordless access. Operationally, that can be useful during migration, but it also extends the period in which teams must manage two authentication paths for the same account. The architecture is therefore not just about adopting passkeys. It is about controlling coexistence while the environment moves from reusable secrets to device-bound authentication.
Practical implication: define migration rules for accounts that temporarily support both passwords and passkeys.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
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
Passkeys improve authentication strength, but they do not solve shared-account governance. The control change is real, because phishing-resistant sign-in is stronger than password reuse. But the ownership problem remains, and shared access still needs enrolment, review, and revocation discipline. Practitioners should not confuse stronger login with complete governance.
Shared-app access creates an identity lifecycle problem, not just an authentication problem. If several people can use one app access path, the organisation still has to answer who is entitled, who approved it, and who removes it. That makes JML and access review processes just as important after passkeys as before them. The practitioner conclusion is simple: lifecycle controls must govern the account, not only the sign-in method.
Passkeys expose the limits of password-centric policy language. Many password policies focus on creation, rotation, and storage, but passkeys change the relevant control set. The named concept here is shared-access revocation gap: when authentication improves faster than offboarding and audit workflows, the real residual risk becomes unowned persistence, not password weakness. Teams need to govern that gap directly.
Passwordless shared access will push IAM teams toward device-mediated control models. That does not eliminate privilege, but it changes where enforcement happens. Policy, logging, and revocation need to follow the device and the account relationship together. For IAM and IGA programmes, the practical implication is that authentication modernisation must be matched with ownership and lifecycle governance.
Passkeys are most useful when they are treated as part of a broader non-human and shared-access governance model. Shared-app access often behaves like an NHI-adjacent control problem because access is reused across people, tools, and workflows. That makes the governance question broader than human sign-in alone. Practitioners should evaluate passkeys as one layer inside a wider access model that includes third-party access, revocation, and auditability.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: Third-Party, B2B and Contractor Access Guide
What this signals
Shared-access modernisation will be judged by governance, not just authentication strength. Passkeys improve the front door, but the real programme test is whether ownership, revocation, and audit trails still work when access is shared across people and devices. For IAM teams, that shifts attention from password policy to lifecycle control.
The named concept here is shared-access revocation gap: organisations often improve sign-in security faster than they improve removal workflows. That creates a window where access is easier to use but still too hard to retire, which is where governance debt accumulates.
For practitioners, passkeys are best read as a trigger to revisit account ownership, especially where third-party and shared access already blur responsibility. According to the Ultimate Guide to NHIs, 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
For practitioners
- Map shared accounts to explicit owners Record who is accountable for each shared application account before moving it to passkeys, and require an owner for enrolment, logging review, and revocation decisions.
- Align passkey enrolment with offboarding workflows Treat passkey removal as part of leaver handling so that access is revoked when a user leaves a team, vendor relationship, or support function.
- Preserve auditability across shared-app sign-ins Make sure each passkey-enabled shared account produces logs that identify the enrolling user, the device, and the access event for later review.
- Plan for hybrid authentication during migration Define how long password and passkey access can coexist on the same account, and put a clear date on removing the legacy password path.
Key takeaways
- Passkeys improve shared-app authentication by replacing reusable passwords with device-bound cryptographic sign-in.
- The operational risk shifts from password exposure to ownership, revocation, and auditability of shared accounts.
- IAM teams should modernise authentication and lifecycle governance together, or passwordless access will outpace control discipline.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Passkeys replace weaker password authentication with phishing-resistant, device-bound authentication for shared app access. |
| NHI-10 — Human Use of NHI | Shared app accounts used by multiple people blur the boundary between human action and non-human access paths. | |
| Recommendation — Adopt NHI-04 controls to replace reusable passwords with phishing-resistant authentication for shared app accounts. Apply NHI-10 to govern shared accounts where multiple users rely on the same credentialed access path. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Passkeys change how authenticators are enrolled, used, and removed across shared accounts. |
| Recommendation — Use IA-5 to manage passkey enrollment, lifecycle, and revocation across shared application accounts. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centers on access permissions and how they are enforced when passkeys replace passwords. |
| Recommendation — Review PR.AA-05 to ensure shared-app entitlements remain governed after passwordless migration. | ||
Key terms
- Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
- Shared Account: An account used by more than one person or process, often for convenience in operational environments. In identity governance, shared accounts weaken attribution, complicate auditing and make it difficult to prove who performed an action during production or maintenance activity.
- 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.
- Authenticator Lifecycle Management: Authenticator lifecycle management is the governance of a credential from issuance to renewal, replacement, and retirement. For human identity programmes, it ensures that keys, smart cards, and certificates stay tied to the right user and are removed when the user, role, or device is no longer trusted.
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.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org