Identity: The New Perimeter

If you had to pick one pillar to invest in first, pick Identity. Almost every breach in the last decade started with a stolen credential. Identity is the strongest, most context-rich signal you have. It is also the cheapest pillar to mature — the controls are mostly configuration changes against an identity provider you already own.

The Stack

A modern identity stack has four layers:

1. The directory — the source of truth for users and groups (Entra ID, Okta Universal Directory, Google Workspace, Ping). HR systems feed in; everything else feeds out.
2. The identity provider (IdP) — issues tokens (SAML, OIDC, OAuth2) consumed by applications.
3. The access policy engine — evaluates per-sign-in conditions (Entra Conditional Access, Okta Workflows, Ping policies).
4. The identity governance system — manages lifecycle, access reviews, certifications, separation of duties (SailPoint, Saviynt, Entra Identity Governance).

You want all four. Most organisations have layers 1-2 and partial 3; layer 4 is usually the gap.

Strong Authentication

MFA is not optional. But not all MFA is equal.

The goal: phishing-resistant MFA for all users, especially admins. CISA, NIST, and the US federal mandate all single out phishing-resistant MFA as a non-negotiable.

The most common AitM (Adversary in the Middle) phishing kit is Evilginx. It proxies a legitimate login page in real time, captures the session cookie, and defeats every MFA factor in the table above except the phishing-resistant ones. Move to FIDO2 / passkeys; treat everything else as legacy.

Conditional Access / Adaptive Authentication

Static "require MFA" is the floor. The ceiling is policy that evaluates context at every sign-in:

• User risk — leaked credential, unusual behaviour, anonymised IP
• Sign-in risk — impossible travel, unfamiliar location, anonymous proxy
• Device state — compliant, hybrid joined, marked-as-risky by EDR
• Location — country, trusted network, named location
• Application sensitivity — finance app vs internal wiki
• Client type — browser, mobile, legacy IMAP

The decision is not just "block / allow" but a graduated response: allow, allow with step-up MFA, allow read-only, require compliant device, require Privileged Access Workstation, or block.

A typical policy set for a mid-size org:

1. Block legacy authentication protocols (basic auth, IMAP/POP, older SMTP).
2. Require MFA for all users — phishing-resistant for admins.
3. Require compliant or hybrid-joined device for sensitive apps.
4. Block sign-ins from high-risk countries unless explicitly justified.
5. Require MFA every time for admin role activation (PIM, see below).
6. Block or step-up for high user risk; force password reset.
7. Session controls: shorter token lifetime for risky sessions; revoke on EDR alert.

Just-in-Time and Just-Enough Access

Standing privilege is the biggest risk multiplier. If 500 admins each have permanent global-admin, every one of their accounts is a domain takeover. Two patterns reduce this dramatically:

Privileged Identity Management (PIM)

Admin roles become eligible rather than active. Users self-elevate for a limited window (e.g. 4 hours), often with approval, MFA, and justification. Audit logs record every activation.

Implementation: Entra PIM, AWS IAM Identity Center with permission sets and session policies, GCP just-in-time access via PAM offerings (e.g., Britive, ConductorOne).

Privileged Access Management (PAM)

For deeper systems (Linux servers, network kit, databases), a PAM platform brokers access: credentials are vaulted (no one knows the password), sessions are recorded, and access requires approval. CyberArk, BeyondTrust, Delinea, HashiCorp Boundary are common choices.

Access reviews

Quarterly or annually, managers attest to each report's access. Roles unused for 90+ days are auto-removed. This is the bread-and-butter of identity governance and is where most "shadow admin" problems are caught.

Service Accounts and Workload Identity

Human identity is half the battle. Service-to-service identity is the other half. The traditional approach — long-lived API keys checked into git or stored in app config — is exactly what supply-chain attackers target.

Modern patterns:

The unifying idea: no static long-lived credentials anywhere. The platform attests to the workload's identity, the workload exchanges that for short-lived tokens, and the tokens are scoped narrowly to the resources it actually needs.

Federation, Not Replication

Acquired companies, contractors, and partner ecosystems multiply identities. The Zero Trust pattern is to federate their identity to yours (SAML / OIDC trust) rather than create local accounts. Access is granted to their federated identity with the same Conditional Access rules.

For B2B SaaS, "social login" (Sign in with Google / Microsoft / Apple) is federation by another name and is preferable to letting users invent yet another password.

The Quick Wins

If you read this lesson and want to move tomorrow:

1. Block legacy authentication protocols. One policy. Massive risk reduction.
2. Enforce phishing-resistant MFA on admins. A handful of users, day-and-night difference.
3. Turn on Conditional Access user-risk and sign-in-risk policies. Even at "report only" first, you will see real attacks.
4. Make all standing global-admin roles PIM-eligible. Zero standing privilege at the top.
5. Inventory every service account and rotate every static credential. Migrate to workload identity as you go.

Identity done well makes every other Zero Trust pillar more effective. The next lesson covers the second-strongest signal: the device the request is coming from.