All briefings
Zero TrustCloud Security

Why Zero Trust programmes stall: an executive guide to risk-led security

By Joseph Caxton ·

Organisations commit to Zero Trust to modernise access and reduce the damage an intruder can do once inside the network. Where a programme loses its link to that risk, it can stall, overrun or deliver new tools without reducing exposure. The board carries accountability for the investment and for the risk it was meant to address, so directors need to understand where Zero Trust programmes go wrong and what a risk-led approach requires.

What Zero Trust means in business terms

Zero Trust is a set of security principles that guide how an organisation controls access. The US National Institute of Standards and Technology, in its Zero Trust Architecture publication of August 2020, describes it as a move away from static, network-based perimeters towards controls that focus on users, assets and resources. The core idea is that each request for a resource is authenticated and authorised against policy before access is given, wherever the request comes from.

The UK National Cyber Security Centre frames Zero Trust as removing inherent trust from systems, networks and services, validating every interaction, and granting the minimum access needed to perform a task. Both bodies treat Zero Trust as an approach that an organisation designs and implements over time, shaped by its own architecture, risk appetite and objectives.

Understood this way, Zero Trust is a change to how access decisions are made across the estate. A programme that treats it as a procurement exercise starts from the wrong place.

Where programmes go wrong

Four patterns can stop a programme reducing risk.

The first is to buy a tool and expect it to carry the strategy. The NCSC has observed that in many cases zero trust network access tools are deployed in environments that still treat network location as a primary signal of trust. Where that happens, the tools may be new while the underlying approach continues to rely on broad, network-based access. Zero Trust calls for granular, context-driven access decisions, so where that broad access persists the organisation can have spent money and changed little.

The second is to begin without knowing what the organisation is protecting. Access policy depends on knowing which resources matter, who should reach them, and from what devices. Where that picture is incomplete, policy is built on assumption and can block legitimate work or grant more access than intended.

The third comes from the parts of the estate that cannot adopt Zero Trust cleanly. The NCSC notes that some systems are incompatible with Zero Trust, for example where an application does not support modern authentication methods, relies on unsupported products that cannot be patched, or handles authentication in ways that are difficult to integrate. Where a programme ignores these systems, they remain a route an attacker can use, and the expected reduction in risk may not materialise.

The fourth is treating Zero Trust as a project with an end date. Zero Trust is a change to operations, so policies need to reflect current roles, devices and threats, which means they need owners and regular review. Where no one owns the policy after deployment, it can drift out of step with the business.

What a risk-led approach requires

A risk-led programme starts from the resources that matter most and the harm that would follow if they were compromised. That assessment sets the order of work, so the organisation applies Zero Trust first where it reduces the most risk.

From there, management can sequence the work against a recognised reference. NIST SP 800-207 gives an abstract definition and deployment models that help an organisation plan its architecture. The NCSC zero trust design principles give a complementary, practitioner-level guide for UK organisations. Where a programme maps its decisions to these sources, the board has evidence that the design rests on established guidance and gives it a defensible basis that is independent of any single vendor's model.

A risk-led approach also plans explicitly for the estate that cannot be integrated. The NCSC describes a mixed estate, where systems that are unsuitable for direct integration sit behind a controlled access layer, such as a zero trust proxy or a managed VPN, in a way that preserves security for the wider system. Naming these systems early, and deciding how to contain or replace them, keeps them from quietly undermining the programme.

Finally, a risk-led approach treats policy as a capability to establish, test and maintain. Access policies should be reviewed as roles and threats change, and the organisation should be able to show that a given policy does what it is meant to do. Testing and review provide that evidence.

Questions for the board

  • What risk did our Zero Trust programme set out to reduce, and how will we know whether it has?
  • Do we have a current inventory of the resources we are protecting, and who should be able to reach each one?
  • Which recognised guidance does our architecture follow, and can management show how our design maps to it?
  • Have we identified the systems that cannot adopt Zero Trust, and what is our plan for them?
  • How has the programme changed the way access decisions are made, beyond the tools it has deployed?
  • Who owns our access policies after deployment, and how often are they reviewed and tested?
  • How does the cost and progress of the programme reach the board against the risk it was meant to address?

A Zero Trust Discovery and Roadmap establishes where the organisation stands, which use cases justify investment based on business risk, and a phased roadmap with investment priorities.

References

Start the conversation

Facing this in your organisation?

Talk to us

We use analytics cookies to understand how this site is used. See our Privacy Notice for details. You can change your choice at any time.