Identity Is the Root. Proof Is the Gate.

Identity is the root of trust in a zero-trust architecture because every other control is downstream of it. Segmentation decides which identities may reach which services. Least privilege decides which identities may perform which operations. Audit records which identity did what. Anomaly detection compares behaviour against a baseline attached to an identity. None of these mechanisms produce identity; all of them consume it.

The proof collected at the gate is therefore a hard ceiling on everything above it. If it establishes only that somebody held a password an hour ago, a policy engine evaluating a thousand attributes is still deciding on the authority of that password.

The perimeter model worked because the network boundary corresponded to a physical one: being inside the cable plant was evidence that somebody had entered a building and been issued a port. Once the workforce is remote and half the integrations are SaaS-to-SaaS, that correspondence is gone. The boundary survives as a configuration object. It no longer refers to anything.

What follows is not a decision but a drift. Access control has to rest on something, and the only thing left that travels with the request is the identity claim. Organisations that never held a zero-trust workshop end up identity-centric anyway — with the same dependency as the deliberate version and none of the scrutiny.

A login is a point-in-time assertion: at one instant, some set of checks passed. Most architectures treat that instant as a durable fact and build hours or days of implicit authorization on top of it. The session cookie, the refresh token, the cached ticket, the enrolled device — each is a mechanism for not asking again.

Continuous proof is the alternative: authorization binds not to a past event but to a context re-evaluated as it changes. Device posture degrades, the scope narrows. Risk signals fire, the session is re-challenged before the next sensitive operation rather than at the next scheduled expiry. The point is not shorter tokens; it is that the authorization decision stops being a memory.

The word "authenticated" covers at least six distinct claims that fail in distinct ways. Separating them is the most useful thing an architect can do to an existing design.

That a secret is present. Somebody supplied a value only the legitimate party should know. This fails to theft, reuse and disclosure, and binds to no person.

That a device is present. A key in hardware signed a challenge. Much stronger, and it still proves only that the hardware participated — not who held it, nor whether willingly.

That a human is present. A liveness or biometric check ran. This defeats automated abuse and does nothing against an accomplice or a coerced user.

That the human is the right one. The biometric matched an enrolled template. This is only as good as enrolment, usually the least scrutinised flow in the system.

That the human understood what they approved. Nothing in a signature establishes this. Whether the screen described the transaction being signed is a property of the interface, not the cryptography. Strictly, this is not an authentication claim at all, and that is the point: the architecture above treats it as one.

That the approval is bound to the specific transaction. The signature covers the actual amount, recipient and operation, and cannot be replayed against another. Systems that get the first five right and this one wrong fail catastrophically, because every layer above assumes the binding holds. None of this is new: PSD2's strong customer authentication rules require dynamic linking of the authentication code to the amount and payee (Article 5 of the RTS), and the W3C's Secure Payment Confirmation does the same for WebAuthn.

NIST SP 800-63B-4 (2025) defines phishing resistance precisely: the authenticator must stop the secret from reaching an impostor verifier without relying on the vigilance of the claimant, and only channel binding or verifier-name binding qualify. It also requires AAL2 verifiers to offer at least one phishing-resistant option. Origin-bound authentication, WebAuthn and FIDO2 credentials that refuse to sign for a domain they were not registered against, is verifier-name binding. It removes credential phishing and real-time relay of the login ceremony structurally rather than by detection. It does not protect the session token issued afterwards, a compromised client, or a misissued certificate for the real domain. Any architecture that can adopt it should.

Origin binding solves relay of the login. It does not solve a user approving the wrong thing in the right interface. If an attacker persuades the legitimate user to initiate a plausible transfer on the genuine site with the genuine key, every check passes, because each was built to answer a different question. Origin binding says nothing about comprehension or transaction binding, and that is where the social-engineering losses described below occur.

Estonia is a useful test case. Since the 2017 ROCA flaw was fixed by reissuing the affected ID-card keys, nobody has shown a practical break of the eID cryptography. Smart-ID splits its private key between the app and SK's server, Mobile-ID keeps its key on the SIM, SK publishes the relying-party API documentation, and the national PKI is competently run. Yet the Information System Authority (RIA) counted €29 million in fraud losses in 2025.

RIA's 2025 review describes victims "entering PIN codes when they should not have" while on the phone with fraudsters, and fraudsters opening new Smart-ID accounts in a victim's name: failures at the approval and enrolment layers, not the cryptographic one. One caveat keeps this honest. The classic Smart-ID flow, a notification plus a verification code the user is meant to compare, is not phishing-resistant in NIST's sense, because the comparison is exactly the vigilance the definition excludes. So Estonia does not show phishing-resistant credentials failing. It shows strong cryptography failing at the approval layer. Origin or channel binding would close the relay; SK's Smart-ID+, available to integrators since June 2025 and live at Bigbank from 11 June 2026 and LHV from 16 June 2026, makes vishing much harder, and on the same device it is, in the assessment of the researcher Arnis Paršovs, fully phishing-resistant. It does not close the gap where a fraudster in live contact talks the victim through a QR flow, as LHV itself has said. Nothing in the protocol fixes the comprehension gap. My Smart-ID analysis looks at what the verification code and confirmation screen establish for the person tapping the button, as opposed to what the protocol establishes for the relying party.

The PIN analysis shows the same thing from the contract side: the design assumes the PIN never leaves the subscriber. Whenever it does, to a caller claiming to be the bank or to software acting for the user, the cryptography operates perfectly and the claim it produces is false. In any system with a competent cryptographic layer, the approval layer holds the remaining risk, because it is the only layer whose correctness depends on a human parsing a sentence under time pressure.

Identity-first is often read as "put identity everywhere", which produces a worse system than the one it replaces. Raw identity in every request is a tracking surface and a forgery target. An API gateway does not need to know who you are, only whether this call is allowed.

The useful construction converts identity and context into scoped, short-lived, verifiable proof. Identity is the root: who or what is acting, including device health and workload identity. Proof is the gate: an authorization server weighs identity, posture and risk together and issues a token carrying an issuer, audience, scope and expiry. Runtime signals decide whether the gate stays open. I prefer feeding them back into the issuer. The OpenID Shared Signals Framework and CAEP (final since September 2025) let enforcement points act on signals directly, which is a legitimate design, but then each one needs a defined precedence rule, or the token and the signal will disagree.

The distinction is between a passport and a boarding pass. A passport says who you are. A boarding pass says what you may do next: this flight, this time, this gate. Enforcement points should be reading boarding passes.

Bind authorization to a re-evaluated context rather than a past event: short token lifetimes with re-evaluation on refresh instead of silent extension, sender-constrained tokens bound to the presenter (DPoP, RFC 9449, or mutual TLS, RFC 8705) so a stolen token is not a usable one, rich authorization requests (RFC 9396) that state exactly what is allowed, and a fresh-proof requirement for state-changing operations while cheap reads run on a cached verdict.

Treat recovery and delegation as part of the authentication surface. Account recovery, PIN reset, device re-enrolment, power of attorney and support-desk impersonation all mint an identity claim, and are almost always weaker than the path they bypass. A hardware-backed primary factor with a call-centre recovery flow behind it sets your real assurance level at the call centre.

Design the approval screen as a security control, because it is one. State the actual operation, counterparty and amount, in the user's own language, where the key is used. If the interface cannot express what is being signed, the signature does not mean what the architecture above it assumes.

None of this is finished work. Hardware-attested identity, scoped proof tokens, continuous evaluation and shared security signals all exist, but integrating them across trust domains under real latency budgets is open engineering. Traffic should not say: this is who I am. It should say: here is proof that I may do exactly this.