Why do organisations need zero trust when data breaches keep growing despite higher security spend?

Zero trust reduces the risk that a single compromised account or device can move freely through an environment. By continuously verifying identity, validating device posture, and limiting access to only what is needed, it removes the assumption that internal traffic is safe. That matters when attackers target credentialed access and perimeter defenses no longer provide enough protection.

Why zero trust remains necessary even when breach spending keeps rising

Higher security spend does not automatically change the attacker’s starting point: a valid account, a trusted device, or an internal foothold. Zero trust is the architectural response to that reality. It assumes compromise is possible, then narrows what any identity can reach, how far it can move, and which requests should be trusted at all.

The key shift is from perimeter confidence to per-request verification. That matters because many modern breaches succeed after the first credential, token, or session is obtained. Zero trust is designed to make that first compromise less useful by reducing lateral movement and limiting the blast radius of any single failure.

What zero trust changes in breach defense

Traditional defenses often work best at the boundary, but breaches now frequently begin inside the boundary through phishing, token theft, exposed secrets, or third-party access. Zero trust does not assume that internal traffic, corporate networks, or previously authenticated users are safe. It requires continuing checks on identity, device posture, context, and policy before access is granted or extended.

That changes the security outcome in practical terms. If an attacker gets one set of credentials, they should not automatically inherit broad access to file shares, admin portals, SaaS consoles, or production systems. The model is built to force more granular decisions, so compromise of one control does not become compromise of the whole environment.

For the underlying architecture, the most relevant reference point is NIST SP 800-207 Zero Trust Architecture, which frames never-trust-always-verify, least privilege, and explicit policy enforcement as the core design shift.

Why spend alone does not stop credentialed attacks

Rising budgets often improve tooling, coverage, or operational scale, but they do not eliminate the structural problem of excessive trust. Attackers increasingly work with legitimate access paths, and those paths can bypass controls that were never designed to contain a trusted insider or a compromised session. That is why organizations can spend more and still see breaches grow.

Zero trust helps most where the real weakness is trust concentration. If authentication, device checks, and authorization are treated as one-time gates instead of continuous conditions, an attacker who clears the front door can keep moving. Zero trust breaks that assumption and forces the environment to re-evaluate access more often, with less implicit trust in network location.

Where workload and service-to-service access are part of the problem, Guide to SPIFFE and SPIRE is a useful implementation reference because it shows how workload identity, attestation, and mutual TLS support stronger east-west trust boundaries.

What organisations should expect zero trust to solve, and what it will not

Zero trust is not a breach-prevention guarantee. It is a containment and validation model that reduces the damage when prevention fails. If credentials are stolen, an endpoint is compromised, or a vendor path is abused, the organization still needs detection, response, and recovery. Zero trust simply makes those events less likely to become enterprise-wide incidents.

The practical expectation should therefore be narrower and more realistic: fewer implicit trust paths, smaller blast radius, more difficult lateral movement, and better control over privileged actions. If the environment still has broad standing access, flat internal networks, or shared credentials, the zero trust label will not matter much. The architecture has to be enforced in access policy, segmentation, and identity controls, not just in strategy documents.

For deeper breach context, The 52 NHI Breaches Report illustrates how stolen credentials, exposed secrets, and lateral movement turn an initial foothold into larger compromise. It is a practical reminder that the issue is not just entry, but what happens after entry.

Risk and Threat Considerations

When organisations keep adding tools without reducing trust, they often improve visibility faster than they improve containment. The result is a false sense of control: the environment looks better defended, but a single valid session can still carry an attacker deep into the estate.

Failure mechanism: A compromised identity, device, or session is treated as sufficiently trusted to reuse permissions across internal systems, which enables lateral movement, privilege escalation, and broader data exposure.

Impact: One successful compromise can become multi-system access, longer dwell time, and larger breach scope, especially where internal segmentation and access policy remain weak.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AA-01 — Identity Management, Authentication, and Access Control	Zero trust depends on explicit identity and access decisions for each request.
Recommendation — Enforce identity-based access decisions continuously instead of trusting network location.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	The question centers on reducing blast radius when breaches occur.
	IA-9 — Service Identification and Authentication	Zero trust often applies to service-to-service and workload trust, not only humans.
Recommendation — Limit permissions so a compromised account cannot move broadly. Authenticate services and workloads before permitting east-west access.
NIST Zero Trust (SP 800-207)	Zero Trust Architecture	The subject is the rationale for adopting zero trust as a breach-containment model.
Recommendation — Apply continuous verification, least privilege, and segmentation to reduce implicit trust.
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	Breach spread is amplified when non-human identities have excessive access.
Recommendation — Reduce non-human identity permissions to the minimum required for each action.

Practitioner Guidance

What to prioritise: Start with the access paths that would be most damaging if abused, not with the most visible controls. Privileged users, remote access, service accounts, and cross-environment access usually deserve the first containment work because they collapse the largest amount of trust into the smallest number of identities.

What to verify: Check whether policy decisions are actually being made at request time, not just at login time. If a user can authenticate once and then move laterally for hours without re-evaluation, the environment is still operating with too much standing trust.

Practitioner takeaway: Zero trust is valuable because it assumes the breach will happen somewhere, then prevents that breach from becoming a free pass across the environment.