Zero trust is sold to boards as a product and delivered, when it works, as a multi-year change in how every person, device and system proves it should have access, so directors who approve the budget often cannot tell which they are paying for. This briefing is for board members, chief executives, chief financial officers and the executives who report to them on technology risk. It explains what zero trust means in business terms, why it is now a governance expectation, how programmes are phased and paid for, and the questions and red flags that show whether management is building an architecture or buying a label. It stays at board level. The staged assessment method is in the Zero Trust Maturity Model Guide and the architecture itself in the NIST SP 800-207 Zero Trust Architecture Guide.
The risk in one paragraph
Traditional security assumed that anything inside the corporate network could be trusted. Once an attacker had one valid password or one compromised device, they could move freely, and most large breaches follow that pattern. Zero trust removes the assumption. NIST SP 800-207, published in August 2020, describes it as moving defences from static, network-based perimeters to users, assets and resources, with no implicit trust granted because of network location or who owns the device, and with authentication and authorisation performed before each session. For the business this means a stolen credential or an infected laptop gives an attacker one narrowly scoped door, not the whole building. It is not a product: it is a set of principles applied across identity, devices, networks, applications and data, and it takes years. The board's job is to approve a phased plan tied to the organisation's most important services, insist on measurable progress, and make sure service accounts and other machine identities are not left out.
Why this is a board-level issue now
- One forgotten account can stop the business: in May 2021 attackers entered Colonial Pipeline through a legacy VPN account that was no longer used but had never been disabled, whose password had leaked and which did not require multi-factor authentication. The company shut its pipeline for about six days and paid a ransom of about 75 bitcoin. Zero trust principles, a unique, verified identity for every connection and continuous checking, target exactly this. See the Colonial Pipeline breach.
- Governments have made it the reference model: the US Office of Management and Budget memorandum M-22-09 of 26 January 2022 required federal agencies to meet specific zero trust goals by the end of fiscal year 2024, including phishing-resistant MFA for staff, contractors and partners, a complete device inventory and treating internal applications as if they were on the internet. CISA's Zero Trust Maturity Model and the UK NCSC's zero trust architecture design principles give private organisations a public yardstick, and suppliers to government increasingly meet the same expectations.
- The perimeter has already gone: staff work remotely, applications run in cloud and SaaS, and suppliers connect from their own networks. Spending on the old perimeter protects less every year.
- Machine identities outnumber people: service accounts, API keys and workload identities, and now AI agents, connect to systems constantly. A programme that verifies only employees leaves most connections on implicit trust. See the Zero Trust for AI Agents Guide.
- Budgets are being spent under the label: because many products are marketed as zero trust, boards need a way to tell architectural progress from tool purchases.
What zero trust means for the business
| Principle | Plain-language meaning | Business effect |
|---|---|---|
| No implicit trust from location | Being on the office network or VPN proves nothing by itself | A stolen password or VPN account no longer opens everything |
| Every identity is unique and verified | People, devices, services and agents each have their own identity, checked on every connection | Shared and orphaned accounts, the doors attackers use, disappear |
| Least privilege, per request | Access is granted to one application or data set for one purpose, not to the network | A compromise is contained to a small blast radius |
| Device and context checked | Access considers device health, location and behaviour, not only the password | Infected or unmanaged devices are stopped at the door |
| Assume breach and monitor | Activity is logged and analysed centrally because an attacker may already be inside | Faster detection and evidence for regulators and insurers |
The NCSC's design principles put the same ideas in practical form: know your architecture, give every user, service and device a unique identity, assess user behaviour and device and service health, authorise every request against policy, authenticate and authorise everywhere, focus monitoring on users, devices and services, and do not trust any network, including your own. For the identity core, see the Zero Trust Identity Guide.
Phasing: how a programme is staged
CISA's Zero Trust Maturity Model describes four stages, Traditional, Initial, Advanced and Optimal, across five pillars: identity, devices, networks, applications and workloads, and data, with cross-cutting capabilities for visibility and analytics, automation and orchestration, and governance. The pillars do not have to move together. Boards should expect a plan that moves the pillars protecting the most important services first.
| Phase | Typical timeframe | What is delivered | What the board should see |
|---|---|---|---|
| 1. Foundations | Year 1 | Inventory of users, devices, applications and machine identities with owners; single sign-on and phishing-resistant MFA for remote and privileged access; legacy and orphaned accounts removed; central logging for critical systems | Coverage percentages rising; known high-risk access routes closed |
| 2. Protect critical services | Years 1 to 2 | Application-level access replacing broad VPN access for critical services; device health checks; segmentation around crown-jewel systems; short-lived credentials for workloads | Named critical services moved to the new model; VPN dependency falling |
| 3. Extend and automate | Years 2 to 4 | Policy applied consistently across cloud, SaaS and on-premises; automated provisioning and removal; risk signals feeding access decisions | Fewer standing privileges; faster joiner, mover and leaver changes |
| 4. Optimise | Ongoing | Just-in-time access; continuous evaluation; automated response | Stable or falling incident impact; optimisation tied to risk, not completeness |
Not every pillar needs to reach Optimal. The target should follow the organisation's risk appetite and the value of the service protected. See the CISA Zero Trust Maturity Model Guide.
Cost: where the money goes
There is no standard price for zero trust, and boards should be wary of any single figure. The cost is mostly change, not licences. Directors should ask for a business case that separates these lines:
| Cost line | What drives it | Offsets to look for |
|---|---|---|
| Identity and access | Single sign-on, phishing-resistant MFA, privileged access, machine identity and secrets management | Retired legacy authentication and password reset effort |
| Access brokering and network | Application-level access, segmentation, encrypted internal traffic | Reduced VPN and legacy perimeter spend over time |
| Devices and visibility | Device management and health checks, endpoint detection, central logging | Tool consolidation |
| Legacy remediation | Applications and systems that cannot support modern authentication need upgrading, isolating or replacing | Often aligns with planned technology refresh |
| People and change | Architecture, engineering time, staff communication, process redesign | Faster onboarding and offboarding, fewer access tickets |
The largest hidden cost is usually legacy systems and the machine identities wired into them. NCSC advises mapping the architecture first partly to avoid late discovery of legacy services that do not support zero trust.
Small and large organisations differ: a smaller, mostly SaaS-based organisation can often get most of the benefit within existing licences by enforcing single sign-on, phishing-resistant MFA and device checks in its identity provider, with little bespoke engineering. A large organisation with data centres, operational technology or decades of in-house applications should expect a multi-year programme with dedicated funding, and should fund it in tranches released against measured progress rather than as a single up-front commitment. In both cases, the board should ask what is being retired as well as what is being bought.
Where it sits in the frameworks
| Framework | Reference | What the board should see |
|---|---|---|
| NIST CSF 2.0 | PR.AA-03 | Users, services and hardware authenticated |
| NIST CSF 2.0 | PR.AA-05 | Access permissions defined, enforced and reviewed with least privilege |
| NIST CSF 2.0 | PR.IR-01 | Networks and environments protected from unauthorised logical access |
| NIST SP 800-53 Rev. 5 | AC-3, AC-6, IA-2 | Access enforcement, least privilege, authentication of organisational users |
| NIST SP 800-53 Rev. 5 | SC-7 | Boundary protection, including internal segmentation |
| OMB M-22-09 | Identity, devices, networks, applications, data goals | A public benchmark of concrete outcomes |
Five questions for the board to ask
- What are we protecting first, and why? Name the critical services the first two years cover, and show how the plan reduces the principal risks in our register.
- Can anyone still reach our systems with only a password? What percentage of remote, privileged and supplier access uses phishing-resistant MFA, and how many dormant or shared accounts remain?
- Does the plan include machine identities? How many service accounts, API keys and workload identities do we have, how many have owners, and how many use long-lived secrets?
- How will we measure progress, not purchases? Show the maturity baseline by pillar, the target for each and the evidence behind the scores.
- What happens to legacy systems? Which systems cannot support the model, what is the plan for each, and what is the cost and residual risk?
Red flags in management answers
- "We bought a zero trust platform": a product purchase presented as the programme.
- One maturity score for the whole organisation: hides weak pillars; CISA's model is assessed pillar by pillar.
- People only: no count or plan for service accounts, API keys, workloads or AI agents.
- VPN still the main route to critical systems after two years: network-level trust has not actually changed.
- No owner for legacy exceptions: exceptions accumulate without expiry dates or compensating controls.
- Optimal everywhere as the target: an unaffordable goal that will be cut arbitrarily later.
What good looks like
- A board-approved zero trust strategy tied to named critical services and the risk appetite, with a pillar-by-pillar baseline and target.
- An inventory of users, devices, applications and machine identities, each with an owner. See the NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments guide.
- Phishing-resistant MFA for all remote, privileged and supplier access. See the Phishing-Resistant MFA Guide.
- Critical applications reached through application-level access with device checks rather than broad network access. See the ZTNA Guide.
- Workloads using short-lived, federated credentials instead of stored keys. See the Workload Identity Federation Guide.
- Segmentation around crown-jewel systems and central monitoring of identity and access events. See the Network Segmentation and Microsegmentation Guide.
Where to invest first
- Visibility: a complete inventory of identities, human and machine, devices and applications. Nothing else can be scoped without it.
- Identity: remove dormant and shared accounts, and enforce phishing-resistant MFA on remote, privileged and supplier access. This alone closes the route used at Colonial Pipeline.
- Critical service access: move the most important services from network access to per-application access with device checks.
- Machine identity: owners, rotation and short-lived credentials for service accounts and workloads.
- Monitoring: central logs of access decisions so the board's metrics have evidence behind them.
Metrics to track
| Metric | What it tells the board |
|---|---|
| Remote, privileged and supplier access using phishing-resistant MFA, as a percentage | Exposure to stolen passwords |
| Dormant, shared and orphaned accounts, human and machine | Doors still open on implicit trust |
| Machine identities with a named owner and no long-lived secret, as a percentage | Whether the non-human half of the estate is in scope |
| Critical services reached through per-application access rather than VPN | Real architectural change |
| Maturity stage by pillar against target | Balanced progress, not a single score |
| Legacy exceptions open, with expiry date and owner | Whether exceptions are managed or accumulating |
A 90-day plan
- Days 1 to 30: management presents what zero trust means for the organisation, the critical services in scope and a first inventory of identities, devices and applications, including machine identities.
- Days 31 to 60: management baselines maturity by pillar, closes dormant accounts and MFA gaps on remote and privileged access, and identifies the legacy systems that cannot support the model.
- Days 61 to 90: the board receives a phased, costed plan with pillar targets and the metrics above, and agrees the reporting cadence. See the Board Cyber Risk Reporting Guide.
Common failure patterns
- Starting with network tools before identity: segmentation without good identities just moves the trust problem.
- Leaving suppliers and contractors on old access routes: third-party VPN accounts become the weakest link.
- Exempting service accounts "temporarily": machine credentials keep standing, broad access for years.
- No business owner: zero trust treated as an IT project, so access decisions that need business input stall.
- Measuring tool deployment: licences rolled out instead of access routes closed.
For a fuller list, see Top 10 Zero Trust Mistakes.
Lessons from incidents
Colonial Pipeline is the clearest board-level example because nothing about it was technically advanced. A VPN account no longer in use had not been disabled, its password had leaked, and it did not require MFA. Inside, nothing stopped the attackers reaching systems that mattered, and the company stopped pipeline operations for about six days. The US Justice Department later recovered 63.7 bitcoin of the ransom. Three zero trust basics, an inventory that would have found the account, strong verification of every connection and access limited to specific applications, each address one link of that chain. The lesson for directors is that the first phase of zero trust is unglamorous hygiene, and it is where most of the risk reduction sits.
Practitioner checklist
- Define zero trust for the organisation in one page, linked to critical services and risk appetite.
- Build and maintain an inventory of users, devices, applications and machine identities with owners.
- Remove dormant, shared and orphaned accounts, including supplier accounts.
- Enforce phishing-resistant MFA on remote, privileged and supplier access.
- Move critical services to per-application access with device checks.
- Replace long-lived workload secrets with short-lived federated credentials.
- Baseline maturity pillar by pillar and set risk-based targets.
- Register legacy exceptions with owners, expiry dates and compensating controls.
- Report zero trust metrics to the board at least quarterly.
Standards and references
- NIST: SP 800-207 Zero Trust Architecture
- CISA: Zero Trust Maturity Model
- NCSC: Zero trust architecture design principles
- OMB: M-22-09 Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
How NHI Mgmt Group can help
We provide independent identity and non-human identity risk assessments and board briefings, including how service accounts, API keys, workload identities and AI agents fit into a zero trust programme. Our NHI Foundation Level Training Course helps security and IAM teams govern service accounts, API keys and secrets. Contact us to arrange a briefing.
Related NHI Mgmt Group resources: Zero Trust Maturity Model Guide · Zero Trust Identity Guide · Identity Threat Executive Briefing · Board Briefing: NHI Risk