What breaks when organisations try to use passkeys without browser and TLS protections?

The authentication flow stops being trustworthy if TLS is missing, origin checks are bypassed, or the attacker can inject script into the target page. In those cases, the attacker may still steal a session token or cookie, even though the private key itself is not exposed. The practical failure is session compromise rather than key theft.

Why Passkeys Still Depend on Browser and Transport Integrity

Passkeys reduce phishing and secret reuse, but they do not turn an untrusted browser session into a trustworthy one. The browser still has to prove the right origin, enforce the right script boundary, and carry the ceremony over a protected transport channel. When those conditions fail, the credential can remain intact while the active session is still stolen or redirected.

This matters because teams sometimes treat passkeys as a full replacement for browser hardening and TLS rather than as one layer in a larger trust chain. That mistake shifts attention away from the real failure point: the authenticated session and the page context that asked for it. The NIST Cybersecurity Framework 2.0 is useful here because it frames identity, protection, and monitoring as linked outcomes rather than isolated controls. In practice, many security teams discover this only after a compromised page or weak transport has already turned a strong authenticator into a stolen session.

How the Failure Actually Happens in Practice

A passkey ceremony depends on the browser validating the origin and keeping the request bound to the correct site. TLS protects that exchange from tampering in transit, while browser security controls limit where the authentication assertion can be requested and how scripts can interfere. If an attacker can break either side of that chain, the passkey itself may still resist extraction, but the authentication result can be abused.

The common failure paths are practical rather than theoretical. A user may authenticate on a spoofed or injected page that looks legitimate enough to collect the resulting session token. A compromised script path can trigger requests in a trusted browser context and then hand the session to an attacker-controlled channel. A weak or absent transport layer can also let an attacker alter page content or redirect the user before the passkey flow completes.

Browser origin enforcement must remain intact, or the passkey response can be harvested in the wrong context.
TLS must remain mandatory, or an attacker can tamper with the page and the session establishment path.
Content injection controls matter because script execution can convert a valid login into session theft.
Post-authentication handling must also be hardened, because the practical loss is usually the cookie or token, not the private key.

For broader identity and credential governance, NHIMG’s Ultimate Guide to NHIs is relevant because it shows how trusted identities fail when lifecycle, visibility, and control boundaries are weak. The same lesson applies here: a strong authenticator does not compensate for a weak execution environment. These controls tend to break down when teams deploy passkeys into legacy web stacks that still allow mixed transport assumptions, inline script risk, or brittle reverse-proxy handling.

Where the Real Trade-off and Edge Cases Sit

Tighter browser and transport requirements can increase implementation friction, especially in environments with embedded webviews, legacy SSO bridges, or custom front ends that were never built for strict origin discipline. That trade-off is real, but current guidance suggests treating the browser and TLS layer as part of the authentication system, not as optional plumbing.

One edge case is that organisations may assume passkeys remove the need for session protections such as HttpOnly, Secure, and SameSite handling. They do not. Another is that enterprise-managed devices may feel safer than they are if browser extensions, injected scripts, or compromised pages can still observe the authenticated context. Passkeys are strongest when the web application, browser, and transport path all preserve the same trust boundary.

That is why the right question is not whether passkeys are secure in the abstract, but whether the whole login path still resists interception after authentication completes. If the answer depends on a browser feature or transport guarantee that the environment cannot reliably enforce, the deployment should be treated as high risk rather than merely incomplete.

Risk and Threat Considerations

Without browser and TLS protections, the main risk is not passkey key theft but authentication-context compromise. The attacker objective is to ride a valid login ceremony and then capture, replay, or redirect the resulting session while the user believes the passkey protected them.

Failure mechanism: Missing TLS, weak origin enforcement, or script injection breaks the trust chain around the authenticator. The passkey response stays bound to the credential, but the browser context, page content, or session handoff can be manipulated so the attacker receives the authenticated session material.

Impact: The organisation gets a false sense of phishing resistance while still suffering account takeover, session hijacking, and downstream access to application data, admin functions, or privileged workflows.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	6 — Access Control Management	Passkeys still require secure access/session handling and least-privilege browser trust boundaries.
	8 — Audit Log Management	Session compromise after successful passkey use needs detection and traceability.
	16 — Application Software Security	Origin checks and script injection are application-layer failures that undermine passkeys.
Recommendation — Harden session and access controls around passkey login paths. Log authentication events and session handoffs to spot hijack attempts. Secure web application paths that can weaken browser-authentication trust.
NIST CSF 2.0	PR.AC — Identity Management, Authentication, and Access Control	The question is about preserving trustworthy authentication and access after passkey use.
	PR.DS — Data Security	TLS protects the authentication exchange and session material in transit.
	DE.CM — Continuous Monitoring	Session theft can occur even when passkeys work, so monitoring must detect abuse.
Recommendation — Enforce authentication and access-control conditions that preserve login trust. Protect authentication traffic with strong transport security. Monitor for anomalous session creation and hijacked post-login activity.
MITRE ATT&CK	T1056 — Input Capture	Script injection or browser abuse can capture authentication flow outcomes or session material.
	T1185 — Browser Session Cookie	The stated failure mode is session compromise rather than key theft.
Recommendation — Detect browser-based interception of authenticated sessions. Hunt for theft or reuse of session cookies after login.

Practitioner Guidance

What to verify: Confirm that the login flow is only accepted over enforced TLS, that the browser origin checks are preserved end to end, and that session cookies cannot be read or exfiltrated by injected script. If any one of those assumptions is false, treat the deployment as vulnerable even if the passkey ceremony itself succeeds.

Decision rule: If the environment cannot guarantee secure transport and strong browser-side containment, prioritise session hardening and application isolation before expanding passkey rollout. If legacy front ends, webviews, or reverse proxies weaken origin integrity, the control gap is in the web stack, not in the authenticator.

Practitioner takeaway: Passkeys reduce one class of credential attack, but they do not eliminate the need to trust the browser, the transport, and the post-login session boundary.