Key Takeaways

• The Transport for London (TfL) and Marks & Spencer (M&S) attacks demonstrate the growing importance of identity as the primary attack surface in modern organisations.

• Public reporting suggests both incidents relied heavily on social engineering and compromised identities rather than novel software vulnerabilities.

• The principles described in NIST SP 800-207: Zero Trust Architecture assume that identities, devices and networks may all become compromised and are designed to reduce the impact of successful intrusions.

• Zero Trust should not be viewed as a technology or product. It is an architectural approach that continuously evaluates trust, limits privileges and assumes that attackers may already be present within the environment.

• While no security architecture can guarantee prevention, Zero Trust provides a framework for reducing attacker freedom, limiting lateral movement and improving organisational resilience.

  ---

Protecting your Identity with a Zero Trust Mindset

Austin Miller · April 1, 2025

Statistics provided by the IBM Cost of a data breach report with collected information from 550 organizations impacted by data breaches states that:

Read full story

The cyber attacks affecting TfL and M&S have become two of the most widely discussed security incidents in the United Kingdom over the past two years. Although the organisations operate in completely different sectors, the attacks demonstrate several common characteristics that have become increasingly familiar to cybersecurity professionals. Public reporting indicates that both incidents involved identity compromise and social engineering rather than highly sophisticated software exploitation, illustrating how attackers continue to prioritise trusted access over technical complexity.

Like many modern incidents, relatively little has been publicly disclosed about the complete technical details of either compromise. Organisations rarely publish full forensic investigations, while law enforcement and criminal proceedings often limit the amount of operational information that becomes available. Any external analysis must therefore distinguish between confirmed information, official statements, and informed observations based upon publicly available reporting. This is, in short, an admission that some aspects of the information we have is limited and we should prepare maximally on that minimal information

Zero Trust—Applied

These incidents also raise an important architectural question. If attackers succeed in obtaining valid credentials or convincing an organisation to grant them legitimate access, what happens next? Traditional security architectures often assumed that authentication represented the beginning of trust: once users successfully logged in, they were generally considered trustworthy until they logged out again. Modern enterprise environments are considerably more complex and, as such, that assumption has become increasingly difficult to justify.

This is precisely the challenge that the NIST SP 800-207 seeks to address. Rather than attempting to build an impenetrable perimeter around enterprise systems, Zero Trust assumes that compromise is possible and designs security controls accordingly. Every access request is evaluated continuously, trust is never considered permanent and security decisions are based upon multiple contextual factors rather than authentication alone. Viewed through this lens, the TfL and M&S attacks provide useful case studies for understanding how Zero Trust Architecture is intended to operate.

Zero Trust Is an Architecture, Not a Product

Few concepts in cybersecurity have generated as much misunderstanding as Zero Trust because many vendors describe individual products as “Zero Trust solutions” or organisations frequently equate Zero Trust with multi-factor authentication, software-defined networking or identity management platforms. Although these technologies contribute towards a Zero Trust strategy, none of them individually constitutes Zero Trust Architecture.

NIST instead defines Zero Trust as a collection of principles governing how trust decisions should be made throughout an enterprise. At its core lies a simple assumption: no user, device, application or workload should be trusted simply because it has already been authenticated or happens to exist within the corporate environment. Every request for access should be evaluated individually, using as much contextual information as possible before a decision is made.

This represents a significant departure from traditional enterprise security. Historically, organisations invested heavily in protecting network boundaries. Firewalls, virtual private networks and network segmentation attempted to distinguish trusted internal systems from untrusted external ones. Once users successfully entered the trusted environment, they often enjoyed broad access to internal resources. While privilege management improved considerably over time, many enterprise environments continued to rely upon assumptions of implicit trust following successful authentication.

Modern organisations no longer operate in that manner. Employees work remotely, applications are distributed across multiple cloud providers and third-party suppliers routinely require access to business-critical systems. Networks have become less important as security boundaries because users, applications and workloads now exist almost everywhere. Zero Trust recognises this reality by shifting attention away from network location and towards continuous verification of identity, device health, workload behaviour and contextual risk.

Understanding the Core Components

NIST’s architecture introduces several logical components that work together to make access decisions. Although different technology vendors implement these concepts in different ways, the underlying principles remain consistent. Understanding these components helps explain how Zero Trust would influence the progression of an identity-based attack.

The first component is the Policy Engine. This is effectively the organisation’s decision-maker. Whenever a user or system requests access to a protected resource, the Policy Engine evaluates available information before determining whether access should be granted. These decisions are based upon policy rather than simple authentication success. Identity, device posture, geographic location, workload characteristics, behavioural information and organisational risk tolerance may all contribute to the final decision.

Supporting the Policy Engine is the Policy Administrator, which translates those decisions into operational actions. If access is approved, the Policy Administrator creates the necessary credentials or session information that allows communication to proceed. If access is denied, the Policy Administrator ensures that no trusted session is established. Importantly, these decisions are not necessarily permanent. Policies can be re-evaluated repeatedly throughout an active session as new information becomes available.

The third major component is the Policy Enforcement Point. This is responsible for enforcing the access decision by permitting or denying communication between the requesting entity and the protected resource. Rather than assuming that internal communication should automatically be allowed, every interaction passes through a control point capable of enforcing organisational policy.

Together, these components fundamentally change the relationship between authentication and trust. Authentication becomes only one input into a broader decision-making process rather than the final determination of whether access should be granted.

Zero Trust on Initial Access

Public reporting surrounding both the TfL and M&S incidents suggests that social engineering and compromised identities played important roles during the initial stages of the attacks. Although the complete technical details remain confidential, this aligns with broader industry observations that identity compromise has become one of the most effective methods for gaining entry into enterprise environments. The question therefore becomes whether Zero Trust would have prevented such an intrusion.

The honest answer is that it depends. Zero Trust does not eliminate phishing, credential theft or social engineering. If an employee willingly discloses credentials or an attacker successfully convinces a help desk to reset an account, the initial compromise may still occur. Zero Trust was never intended to guarantee that attackers cannot obtain valid credentials. Instead, it assumes that such compromises will occasionally happen and seeks to minimise the consequences.

This distinction is essential because many discussions oversell Zero Trust as though it were a preventative technology. NIST takes a more pragmatic approach, amd suggests that organisations should assume that identities may become compromised, devices may become infected, and adversaries may occasionally succeed. The architecture therefore focuses on reducing the amount of trust automatically granted after that initial success and working from that point onwards.

Suppose, for example, that an attacker successfully obtains an employee’s username and password through social engineering. Within a traditional enterprise, successful authentication may be sufficient to establish a trusted session, particularly if the account belongs to a recognised employee accessing familiar systems. Under a mature Zero Trust Architecture, however, authentication alone is unlikely to satisfy organisational policy. Additional contextual information would be evaluated before the session proceeds.

Context Matters More Than Credentials

One of the most significant differences introduced by Zero Trust is the use of contextual information during access decisions. Credentials remain important, but they are no longer treated as definitive proof that access should be granted. Instead, organisations evaluate whether the broader circumstances surrounding the request are consistent with expected behaviour.

For example, the Policy Engine might consider whether the device requesting access is enrolled in enterprise management, whether it meets required security baselines, whether recent behaviour has appeared unusual or whether the requested resource aligns with the user’s established responsibilities. Authentication from an unmanaged device, an unfamiliar geographic location or an account suddenly requesting administrative resources could all influence the decision even if the supplied credentials are technically correct.

Applied conceptually to incidents such as TfL or M&S, this approach demonstrates why Zero Trust focuses on reducing attacker confidence rather than preventing every compromise. Even if attackers obtain legitimate credentials, they may still encounter additional policy decisions before meaningful access is established. Sessions may be restricted, additional authentication requested or access denied altogether because surrounding contextual evidence suggests elevated risk.

The practical implication is that successful credential theft no longer guarantees operational freedom. Instead, attackers must continuously satisfy organisational policy throughout the intrusion. This significantly increases the complexity of conducting long-running identity-based attacks because every subsequent action becomes another opportunity for security controls to detect inconsistencies and intervene before greater damage occurs.

Part 2 will examine how Zero Trust limits lateral movement, enforces least privilege, supports continuous monitoring and incident response, and why architectures based on NIST SP 800-207 are designed to reduce the impact—not necessarily prevent the occurrence—of modern identity-based attacks.

Protecting your Identity with a Zero Trust Mindset Austin Miller · April 1, 2025 Read full story

#243: The Entrepreneurial Adversary Austin Miller · Jul 17 Read full story

#244: Comparing Two Modern UK Cyber Attacks Austin Miller · Jul 24 Read full story