Application-level Zero Trust: done with passwords in 2026

A password is a secret shared between a human, a browser, a database, and — far too often — an attacker. This architecture is structurally indefensible: 81% of verified breaches still go through stolen or weak credentials (Verizon DBIR report), and the `haveibeenpwned` corpus now exceeds 14 billion accounts. No complexity policy, no rotation schedule, no password manager changes that fundamental equation.

The only property that holds in 2026 is phishing resistance by design. A secret that never leaves the authenticated device, is cryptographically bound to a specific domain, and cannot be replayed on an imposter site cannot be stolen through a fake login email. That is exactly what FIDO2 / WebAuthn specifies (W3C Recommendation, RTS PSD2 for payments in Europe).

The standard is finally mature. Apple, Google, and Microsoft aligned their platforms on WebAuthn Level 3 back in 2023; synchronised passkeys have been in production since iOS 16.4, macOS 13.5, Android 14, and Windows 11 22H2. Adoption follows: more than 12 billion accounts exposed a passkey option across Google, Microsoft, and Apple in the second half of 2024. For a French SMB in 2026, the question is no longer "is it ready?" but "how much longer do we accept passwords?".

NIS2 (transposed into French law as of October 2024) and the upcoming eIDAS 2 tighten the obligation of means. For essential and important entities, phishing-resistant strong authentication is no longer a best practice: it is an auditable regulatory requirement. The status quo is no longer a defensible option.

A passkey is a cryptographic key pair. The private key lives in an authenticator (TPM, Secure Enclave, FIPS 140 smart card); the public key is registered with the service provider (RP — Relying Party). Authentication produces a signature over a challenge that includes the exact origin (`rp.id`), which makes phishing structurally impossible.

Two families coexist. Synchronised passkeys (Apple iCloud Keychain, Google Password Manager, Microsoft account, third-party managers like 1Password or Dashlane) offer a seamless experience across a user's personal devices. `device-bound` passkeys (keys residing in a non-exportable hardware module: YubiKey, Titan, smart card) offer a higher assurance level (often AAL3 per NIST 800-63B) at the cost of manual recovery.

On the UX side, the promise holds: Face ID on iOS/macOS, Touch ID on Mac, Windows Hello on PC, fingerprint on Android. Authentication becomes a gesture, not a typing exercise. Login success rates exceed 90% on internal deployments measured by Apple and Google, versus 60-70% for a password + TOTP flow.

Recovery remains the hard part. An organisation must decide its strategy explicitly: assisted re-enrolment via an always-connected device (Apple, Google), an administered backup authenticator (a backup YubiKey stored in a vault), or a help-desk reactivation mechanism with strong identity proofing. This part — not the cryptography — determines the success of an enterprise passkey rollout. Plan a dedicated runbook, coverage metrics, and a twice-yearly recovery drill.

Zero Trust is not a product. It is an architecture principle: no request is ever considered legitimate because it comes "from the inside". Every API call, every data read, every session open must be authenticated, authorised, and inspected — regardless of the originating network. The VPN is progressively obsolete as a trust perimeter; it remains useful as an encrypted channel, not as an identity guarantee.

At the application level, this translates to short sessions: access token JWTs of 5 to 15 minutes maximum, asymmetric signature (RS256, ES256, EdDSA), minimal claims (`sub`, `iss`, `aud`, `exp`, `iat`, `scope`), and refresh token rotation on every use (with reuse detection). On storage, the access token stays in memory (or an `httpOnly` + `secure` + `sameSite=lax` cookie), never in `localStorage`.

`session binding` goes further: a cryptographic device fingerprint is issued at authentication and embedded in subsequent tokens via DPoP (Demonstrating Proof-of-Possession, RFC 9449) or mTLS. A stolen token becomes unusable outside the original device. For sensitive operations (MFA change, admin access, wire transfer), a step-up re-authentication is requested via a second WebAuthn invocation.

Anomaly detection completes the setup. Logins from a new ASN, abnormal velocity, repeated failures on one identifier, impossible geography (Paris to Singapore in 30 minutes): every signal feeds a risk engine that triggers an additional challenge, a user notification, or a temporary block. Tools like Auth0 Anomaly Detection, Cloudflare WAF, WorkOS Risk Score, or Supabase Auth hooks let you industrialise these rules without reinventing a SIEM.

September 2022, Uber: an attacker obtains an employee's password (bought on the dark web), then triggers a flood of MFA push notifications. Exhausted, the employee eventually accepts one. The attacker penetrates the infrastructure, accesses secrets stored in a PowerShell file, compromises GCP, AWS, SentinelOne, Duo, and Slack. Real cost: $148 million in declared impact, two years under regulatory supervision, and individuals personally prosecuted.

This attack — known as `push-bombing` or MFA fatigue — works because the push second factor is not phishing-resistant and involves no proof of context. The fixes are now standard. `number matching` forces the user to type a code shown on screen into their phone: without that active step, the push is never approved. Microsoft Entra ID enabled it by default in 2023; Duo and Okta followed.

The factor hierarchy is clear. Phishing-resistant: FIDO2 / WebAuthn (passkeys, hardware keys), then — to a lesser extent — notifications with `number matching` and contextual `phishing-resistant` checks. Not resistant but acceptable: TOTP (Google Authenticator, Authy, 2FAS). To deprecate as soon as possible: SMS and voice (SIM swap, SS7 interception, cost, degraded UX, non-compliance with PSD2 for strong payments).

Since the threat is adaptive by nature, authentication must be too. Risk-based authentication (RBA): a recognised device signs in with a passkey alone; a new device must pass a step-up; an improbable login triggers an explicit challenge. NIS2, the European directive, explicitly encourages this contextual approach. Product-wise, it means less friction for the legitimate user and more for the attacker — exactly the opposite of classic push MFA.

In a modern B2B environment, an employee accesses 80 to 130 SaaS applications on average (2024 Productivity survey). The proliferation of local accounts — each with its password, its MFA, its offboarding process — has become unmanageable and dangerous. SSO (Single Sign-On) is no longer a premium feature: it is the reference architecture, with the Identity Provider (IdP) as the new security perimeter.

Two protocols dominate. SAML 2.0 (OASIS 2005), still ubiquitous in the enterprise: signed XML, `Assertion`, `Response`, HTTP-POST or Redirect binding. More modern, OpenID Connect (OIDC) builds on JSON, JWT, and standardised OAuth 2.1 flows (Authorization Code + mandatory PKCE for SPA/mobile). For any new deployment in 2026, OIDC is the default; SAML remains the minimum interoperability expected by enterprise clients.

For a B2B SaaS, exposing SSO on the enterprise tier is not optional. Okta, Microsoft Entra ID (formerly Azure AD), Google Workspace, JumpCloud, WorkOS, and Auth0 are the references on the corporate IdP side. On the SaaS side, the modern pattern is multi-tenant: each client organisation connects its IdP, the provider isolates identities via `tenant_id` + `org_id` in the claims, and user resolution happens through email or stable-attribute mapping (`sub`, `employeeNumber`).

SCIM 2.0 (RFC 7643 and 7644) completes the story. It automates provisioning and deprovisioning: a directory entry on the client side instantly creates the SaaS account; a departure (JIT or manual) deactivates it. It is the mechanism that prevents orphan accounts — one of the first things a NIS2 or ISO 27001 auditor will check. A serious B2B SaaS in 2026 implements SCIM in read and write; it is the dividing line between a professional tool and a consumer tool slipped into the enterprise.

Quarter 1: deploy passkeys for internal employees. Choose a platform (WorkOS, Auth0, Supabase Auth + WebAuthn, or Cloudflare Access), enable synchronised passkeys on the Apple/Google/Microsoft side as a first wave, and hand out a backup YubiKey to sensitive accounts (administrators, finance, security). Measurable target: 90% of employee logins passwordless within 90 days.

Quarters 2-3: expose SAML and OIDC SSO for B2B clients. Industrialise multi-tenancy, publish integration documentation (XML metadata, OIDC discovery, expected attributes), and recruit 3-5 pilot clients on Okta and Entra ID. Implement SCIM 2.0 in parallel to automate lifecycle. It is also time to enable `number matching` on remaining MFA notifications and to disable SMS except in documented cases.

Year 1: progressively deprecate TOTP and classic push. `passwordless-first` becomes the default UX for new logins. Set up an application risk score and structured authentication logging (user_id, device_id, ip, asn, geoloc, risk_score, mfa_method) streamed to the SIEM. Prepare the removal of the `password-only fallback`: a user with no registered passkey must create one through an enrolment flow, not through a fallback password.

Month 18: fully remove the "password-only sign-in" option. The password survives only as a degraded recovery factor, protected by FIDO2 MFA and help-desk verification. At that point, the credential-stuffing attack surface is reduced to nothing, the user experience improves (less support, faster logins), and the company meets NIS2 expectations for important entities. Internal and external communication must accompany the change: this is a product project, not just a security project.

The first objection we hear on missions: "We haven't had an incident yet." That is precisely the posture that turns a credential leak into a major incident. The marginal cost of a progressive passkey rollout (one quarter of concentrated product + IT effort) is trivial compared to the cost of an Uber-style incident: NIS2 fines up to €10 million or 2% of revenue, CNIL notification within 72 hours, and B2B client trust damage that is often irreversible.

The second objection: "Our clients aren't asking for SSO." True today, false in 18 months. Every CIO of a French mid-cap above 200 employees now runs a `no-SSO, no-purchase` policy. Client IT departments' SSO maturity has thickened since 2023; a SaaS without SAML/OIDC loses deals, especially in regulated markets (banking, health, defence, industry).

The third objection: "It's too early to remove the password." Technical reality says otherwise: passkeys are supported by 100% of modern browsers (Chrome, Safari, Firefox, Edge), by the three dominant mobile ecosystems, and the major IdPs (Okta, Auth0, WorkOS, Supabase, Microsoft Entra) expose stable APIs. The real technical risk in 2026 is not the standard — it is the recovery runbook and change management.

At VALRY LABS, we systematically advise SMBs and mid-caps to treat this migration as a full-fledged product project: an identified executive sponsor, a dedicated budget, published metrics (passwordless login rate, number of accounts without a phishing-resistant factor, incidents avoided), and a quarterly retrospective. Treating authentication as technical debt to be repaid slowly is the costliest mistake we see in the field.