Authentication news · Sources checked November 7, 2026
A successful sign-in is only part of a safe access rollout. When a new login method changes which identity information reaches an application policy, the most important test is whether the right people still get in and everyone else stays out.
What changed in Cloudflare Access
Cloudflare’s November 6 announcement adds passkey sign-in for Access-protected applications and the App Launcher. A credential stored on a device, security key or password manager can replace the repeated one-time PIN flow. Users first verify their identity through an existing login method to enroll, and administrators control which applications accept the new method.
For a small team protecting an internal tool, that can make returning access simpler. The useful deployment question is what happens before the first credential exists, after it is lost, and when the user’s role changes. This article proposes a review plan; it does not report a hands-on test of the new feature.
The group-membership gap deserves attention
The passkey documentation says authentication does not fetch another identity provider’s groups or custom attributes. It also specifies that enrollment uses an email verification code when passkeys are the application’s sole login method. Removing the other login buttons therefore does not remove email from that enrollment path.
Consider a fictional support dashboard whose intended audience is the support team. Before the change, a successful corporate login and the expected group claim formed part of the review. A passkey pilot should include a support employee, an employee outside support, a former team member and an unrelated test identity. Record the expected decision for each identity before running the tests. An attractive sign-in screen is not evidence that those four decisions are correct.
Keep the policy narrow while investigating a failed pilot. Replacing a group requirement with a broad email-domain rule may get a test user working, but it changes the intended audience. Treat that as a separate authorization-design decision, with its own owner, rather than a troubleshooting shortcut.
Inspect the actual policy logic
Access policy documentation separates actions, rule types and selectors. Multiple Include criteria act as alternatives; Require criteria must all hold; matching Exclude criteria prevent access. Access is deny by default. Review the whole policy set and its ordering, not just the new login option.
Make a short application inventory: intended users, permitted login methods, identity attributes needed, device requirements, policy owner and recovery contact. Flag any application that accepts every available identity provider for explicit review before introducing another provider. For each pilot case, capture the login method, policy result and whether the protected application actually opened. Use synthetic identities and non-sensitive test content.
Credential removal and session revocation are separate jobs
Cloudflare’s passkey guide distinguishes blocking a deleted credential’s future sign-ins from ending active Access sessions. Its session-management documentation provides user- and application-level revocation, while warning that an identity which remains eligible may establish another session.
Write the lost-device runbook as three questions: which credential must stop working, which existing sessions must end, and which other authentication paths remain available? Offboarding adds a fourth question: what stops the person from enrolling or signing in again? Assign these checks to named operational roles. Do not assume that one successful delete operation answers all of them.
A bounded pilot with a clear exit
- Choose one low-risk application. Agree on the intended audience and keep the current supported recovery route available during the pilot.
- Test fresh enrollment and returning access separately. Include a new browser profile, the devices people actually use, and an unavailable-authenticator scenario. Note which steps need email or support help.
- Test allowed and denied identities. Include a deliberate role change. Compare observed decisions with the written expectations rather than accepting any successful login as a pass.
- Rehearse recovery with a test account. Check a new sign-in and an already-open session independently. Time the procedure and identify who can complete it outside normal support hours.
- Set the expansion decision in advance. Expand only when expected allow/deny outcomes, recovery and user instructions are demonstrated. If a case fails, pause expansion and correct the configuration without broadening the audience just to clear the test.
The deliverable is a small evidence sheet, not a feature checkbox: application, tested identities, login routes, decisions, recovery result, known limitations and a responsible owner. That gives the next administrator something more useful than “passkeys enabled.”