Passkeys in Cerby shift shared-app access toward phishing resistance

At a glance

What this is: This is an analysis of passkeys for app access, showing how cryptographic authentication can reduce password dependence while improving control over shared logins.

Why it matters: It matters because IAM teams must decide where passkeys fit across human sign-in, shared application access, and the governance of credentials that were previously handled as passwords or secrets.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Cerby's passkey guidance for shared app authentication and setup detail

Context

Passkeys are a passwordless authentication method based on public-key cryptography, where a private key stays on the user’s device and the public key is used by the app or service to verify access. In practice, they reduce phishing exposure because there is no password to steal, but they do not remove the need for governance over who can register, use, and revoke access in the first place.

For IAM teams, the real issue is not whether passkeys are stronger than passwords, but where they fit in the control stack. In shared-app and delegated-access scenarios, passkeys change the authentication factor, but they do not automatically solve lifecycle, offboarding, auditability, or accountability across the identities that use those apps.

Key questions

Q: How should security teams govern passkeys for shared application accounts?

A: Security teams should treat the shared account as the governed object and the passkey as the authentication method attached to it. That means assigning ownership, controlling enrolment, logging usage, and removing access when the user, device, or business relationship changes. Without those lifecycle controls, passkeys can improve login security while leaving accountability problems intact.

Q: Why do passkeys reduce phishing risk but not governance risk?

A: Passkeys reduce phishing risk because there is no reusable password for an attacker to steal or replay. They do not reduce governance risk because organisations still need to manage who can register the passkey, how it is recovered, and when access should be revoked. Stronger authentication does not replace lifecycle discipline.

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: How do passkeys fit into broader IAM and zero trust programmes?

A: Passkeys fit best as part of a broader IAM and zero trust model that also governs device trust, access scope, and revocation. They improve the authentication step, but zero trust still requires continuous verification of identity, device, and policy state across the access lifecycle.

Technical breakdown

How passkeys use public-key cryptography for app authentication

Passkeys split authentication into two parts. The private key remains on the user’s device and is unlocked locally with biometrics, a device PIN, or a security key. The public key is registered with the app or website and is used only to verify the cryptographic challenge at login. Because the secret never leaves the device and no reusable password is typed or transmitted, phishing and credential replay become much harder. The control is strongest when the relying party binds the passkey to the correct domain and the device trust signal is maintained throughout the login flow.

Practical implication: treat passkeys as an authentication control, not an identity governance control, and still manage registration, recovery, and revocation centrally.

Why passkeys reduce password attack surface in shared-app workflows

Shared accounts are risky because passwords are transferable, reusable, and often copied into low-control channels. Passkeys replace that shared secret with device-bound cryptographic proof, which narrows exposure and removes much of the human handling that creates leakage. For third-party apps, this matters because the login method becomes harder to phish and easier to trace back to the device and user approval event. But traceability is not the same as lifecycle control. If the underlying account remains shared, access still depends on how well the organisation governs enrolment, device trust, and offboarding.

Practical implication: pair passkeys with account ownership rules so shared access is revocable when roles, vendors, or devices change.

Passkey vaulting and admin controls in a managed access model

In a managed model, the passkey is not just a user convenience feature. It becomes part of the access control plane, with storage, policy enforcement, and logging tied to the organisation’s governance process. That introduces an IAM question that goes beyond authentication strength: who is allowed to create a passkey, where is it stored, how is it recovered, and what evidence exists when access is removed? Those questions are especially relevant when passkeys are used to replace passwords for business apps that still need auditability, delegation tracking, and lifecycle offboarding.

Practical implication: define passkey enrolment, storage, recovery, and deletion procedures before rolling the control out to high-value applications.

Threat narrative

Attacker objective: The objective is to gain persistent access to business applications through compromised shared credentials or weak authentication controls.

1. Entry occurs through stolen, reused, or phished passwords in shared application accounts, which passkeys are designed to reduce by replacing the reusable secret with device-bound cryptographic proof.
2. Escalation occurs when attackers or unauthorised users exploit weak password handling, shared credential reuse, or poor offboarding to continue using the account without triggering strong authentication friction.
3. Impact is the abuse of delegated or shared app access, where unauthorised sign-in can lead to data exposure, account takeover, or fraudulent actions inside the third-party service.

Breaches seen in the wild

• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

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

NHI Mgmt Group analysis

Passkeys strengthen authentication, but they do not solve identity governance. A passwordless login flow removes a reusable secret, yet the organisation still has to decide who can create, inherit, recover, and revoke access. The control shifts the problem from password handling to lifecycle governance, which is where many programmes are weakest. Practitioners should treat passkeys as one control in a broader identity model, not as a complete access strategy.

Shared access changes the governance burden, not the security category. If a business app still depends on shared accounts, passkeys reduce exposure to password theft but do not eliminate the need for ownership, audit trails, and timely offboarding. The failure mode moves from password sprawl to passkey governance sprawl if enrolment and deletion are not controlled. The practitioner implication is that the account, not the factor, must remain the governed unit.

Passkeys reveal the difference between stronger login and stronger accountability. The login ceremony can become phishing-resistant while the underlying access model remains opaque. That gap matters in high-risk workflows where a single app login can influence customer data, financial actions, or vendor administration. Security teams should read passkeys as a signal to tighten governance around the account lifecycle, because the authentication layer is now stronger than the process that surrounds it.

Credential-less login is becoming a design expectation, but governance must catch up. As more applications support device-bound authentication, teams will be expected to reduce password reliance across human access and shared application access. The operational question is no longer whether passwords are weak, but whether the programme can govern device-bound access with the same discipline it once applied to secrets. That is a lifecycle problem as much as an authentication problem.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Passkeys reduce password exposure, but lifecycle governance still matters across identity programmes. See Ultimate Guide to NHIs , Key Challenges and Risks for the surrounding control gap.

What this signals

Passkeys are becoming the authentication layer that many programmes wanted passwordless identity to be, but they do not compress the governance workload. As organisations move shared-app access away from passwords, the pressure shifts to enrolment control, recovery discipline, and revocation evidence. Teams that treat passkeys as a point solution will likely create a new class of unmanaged access unless they align them with lifecycle policy and application ownership.

91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures. That same operational lag is why passwordless rollouts need stronger offboarding and incident response hooks, not just better authentication. If access cannot be removed quickly and cleanly, the new login method only masks the old governance delay.

Passkey adoption should sharpen the programme’s focus on account lifecycle, not broaden its enthusiasm for passwordless branding. The right next step is to bind authentication improvements to measurable control outcomes, including revocation speed, audit completeness, and device-bound access ownership. That is where the governance model either proves itself or fails.

For practitioners

• Map passkey use to account ownership Inventory which applications use passkeys for shared or delegated access, then assign a clear owner for enrolment, recovery, and deletion decisions.
• Define recovery and revocation workflows Document how a passkey is removed when a user leaves, a device is lost, or a vendor relationship ends, and make the workflow auditable.
• Separate authentication strength from lifecycle control Review whether the account can still be misused after a passkey is issued, especially where the same login is shared across teams or third parties.
• Keep passwordless access within governed apps Prioritise passkeys for applications where you can enforce enrolment policy, device trust, and logging, rather than for unmanaged shared logins.

Key takeaways

• Passkeys improve the authentication step by removing reusable passwords, but they do not remove the need for lifecycle governance.
• Shared application access becomes safer only when enrolment, recovery, audit, and revocation are controlled with the same discipline as login itself.
• IAM teams should evaluate passkeys as part of broader account governance, not as a standalone fix for identity risk.

Key terms

• Passkey: A passkey is a passwordless credential that uses public-key cryptography to verify a user without sending a reusable secret. The private key stays on the user’s device, while the public key is registered with the app or website for challenge-response authentication.
• Passwordless Authentication: Passwordless authentication is any sign-in method that does not rely on a shared password. In practice, it shifts verification to stronger factors such as device-bound cryptography, biometrics, or security keys, but it still requires governance over registration, recovery, and revocation.
• Shared Account: A shared account is a single application identity used by more than one person or team. It can simplify access to vendor tools or business apps, but it complicates accountability, offboarding, and evidence collection because activity is tied to the account rather than to one unique operator.
• Device-Bound Credential: A device-bound credential is an authenticator that can only be used from the device where it was created or stored. This reduces replay and phishing risk, but it also means organisations need recovery and deletion processes that account for device loss, replacement, and role changes.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Cerby: Passkeys in Cerby. Read the original.