Identity as the Perimeter

Once you accept that the network grants no trust, something else has to be the boundary. That something is identity. The question at every access is no longer "what subnet are you on" but "who are you, on what device, asking for what, right now, and does policy allow it." Get identity right and the rest of zero trust has a foundation. Get it wrong and every downstream control inherits the weakness.

A verified identity by itself is not the whole decision. The decision reads a bundle of signals at request time and returns allow, deny, or "allow but prove more." This is conditional access, and it is the working heart of identity-as-perimeter in Entra ID, Okta, and every serious identity provider.

Signals feed the decision

A useful conditional access policy weighs several inputs, not just a password.

• User risk: has this account shown signs of compromise, like impossible travel or credentials found in a breach dump?
• Device posture: is the device managed, compliant, patched, and running its endpoint agent? An unmanaged laptop should not reach payroll no matter whose password it holds.
• Location and network: not as a trust signal, but as risk context. A login from a country the user has never worked in raises the bar.
• Resource sensitivity: reaching the cafeteria menu and reaching the source repo are not the same request and should not clear the same check.

The policy combines these into an outcome. Low risk, compliant device, normal resource: allow. Same user, unmanaged device, sensitive app: block, or force step-up authentication with a hardware key before granting the session. A clean way to reason about the rule is the Kipling method, answering who, what, when, where, why, and how for the access before you write it.

Continuous verification, not a golden hour

Here is the failure most identity setups still ship with. The user authenticates once, gets a token valid for an hour, and for that hour the system stops checking. Disable the account, and the stolen token keeps working until it expires. That hour is a gift to an attacker sitting on a hijacked session.

Continuous verification closes the window. Instead of trusting a token until expiry, the system re-evaluates when conditions change. Entra's Continuous Access Evaluation is the concrete version: revoke a session, flag the account as risky, or detect the device fell out of compliance, and the access token is invalidated in near real time rather than after sixty minutes. Verification becomes an ongoing state, not a one-time gate at the front door.

$az ad signed-in-user show --query 'userPrincipalName'

The one control that anchors all of this is phishing-resistant MFA. FIDO2 or WebAuthn keys bind the login to the real site and a physical authenticator, which defeats the credential phishing and MFA-fatigue push spam that beat SMS and prompt-based methods. If your identity perimeter still allows SMS codes or plain push approval on sensitive resources, that is the crack an attacker aims at first.