Zero trust in twelve months: the sequence that works for 2,000 people

Zero trust is an architecture, not a product category

NIST's definition is narrower than the marketing. A zero trust architecture grants no implicit trust to an asset or an account because of network location or ownership, and it authenticates and authorizes the subject and the device before a session to a resource is established. It protects resources, not network segments.

For a 2,000-person company with one identity provider, a VPN and a few hundred applications, the working sequence is dependency order: identity, device trust, segmentation and brokered access, then workload identity, then data controls. Each phase produces the inventory the next consumes, so a platform bought in month one sits idle by month four.

Identity first, and what has to be true before it works

CISA says to start with administrative accounts and the people who handle sensitive data, then extend multifactor authentication everywhere. Its ranking of factors matters more than the enrolment percentage: a physical security key protects best against phishing, an authenticator app with number matching comes next, then one-time codes and biometrics, with text and email codes weakest.

A joint advisory with the NSA that CISA points to lists weak or misconfigured MFA among the most exploited misconfigurations in large organisations, which describes an estate where the prompt appears but a legacy protocol bypasses it. Report the share of sign-ins that used a phishing-resistant factor, not the share of accounts with MFA switched on.

Device trust turns a sign-in into an access decision. In Microsoft's conditional access model, policies run after first-factor authentication and can require a compliant or joined device, and blocking legacy authentication protocols is a standard policy. Four things must be true first: an authoritative joiner, mover and leaver feed; a device inventory something reports; one policy engine the applications trust; two break-glass administrators no policy can lock out.

The twelve-month sequence

The table is the sequence for an estate this size. The months overlap, but each phase has one exit condition: it is finished when its output is complete enough for the next phase to rely on. Starting brokered access while a third of the laptops cannot report compliance turns a security programme into a service desk backlog.

Two rules keep the schedule honest. No phase gets tools budgeted until the inventory it depends on has an owner and a refresh date. Every exception is time-boxed and named, and the count of live exceptions goes to the steering group each month.

Segmentation, ZTNA and the applications that cannot do SAML

Brokered access replaces the question of whether a machine sits on the network with a decision per application. The broker authenticates the user and the device, checks policy, and connects that person to one application rather than handing out a tunnel to a subnet. NIST frames enforcement the same way: each request is authorised, not inherited from an earlier session.

Then the legacy estate arrives: applications that speak neither SAML nor OIDC, thick clients holding a direct database connection, shared local accounts on a server nobody wants to touch. Four answers work: an identity-aware proxy in front where the application speaks HTTP; a connector on the application server; a brokered RDP or SSH path with session recording; a privileged access vault with checkout for shared accounts. The bad answer is a network exception that outlives the project.

An application nobody owns is the real blocker, because an owner approves the change, tests the break and pays for the fix. Ownership should be a precondition for the exception list. With no owner, migrate the function or record the risk at the level that carries it.

Factory and building networks need their own track. NIST's operational technology guidance is written around systems whose performance, reliability and safety requirements differ from office IT, and agents built for laptops often have no place on a controller. Segment those networks, restrict administrative access to a jump host, and let that estate mature slowly.

Workload identity and least privilege in the cloud

Machine credentials outnumber human accounts in most cloud estates, which is why this phase gets underestimated. NIST's cloud-native model describes the shift from segmentation by network parameters to authorization by application and service identity, enforced by API gateways, sidecar proxies and identity infrastructure such as SPIFFE, on premises or across several clouds.

The work is unglamorous: enumerate service accounts, pipeline tokens, API keys and managed identities; replace long-lived secrets with short-lived credentials issued to a workload; use mutual TLS between services; scope roles to the resource rather than the subscription. A pipeline breaks the moment a static key is deleted, so the replacement lands first.

Least privilege then becomes countable: standing privileged roles per cloud account, the age of the oldest active key, the share of service-to-service calls carrying a workload identity, and the number of administrators whose rights are granted just in time.

Where the programme stalls, and what a board will accept

The phase that stalls most often is device trust, and the cause is inventory quality rather than the tool. Conditional access can only act on device state that something authoritative reports; when the management record is stale, policy blocks people who should be allowed in, and someone grants an exclusion to close the ticket.

Measurement is where programmes lose funding, because zero trust has no single percentage. CISA's maturity model gives a usable frame: five pillars, for identity, devices, networks, applications and workloads, and data, plus three cross-cutting capabilities, each scored from traditional through initial and advanced to optimal. Auditors map that to controls, and boards read stage movement without a glossary.

Five counts matter underneath that language: sign-ins using a phishing-resistant factor, devices reporting a compliant state, applications behind the broker against the total, standing privileged roles per cloud account, and inspected egress paths.

None of this starts with a product decision: strong identity, true device state, access decisions taken at the application, and data controls following a classification the business will maintain.