Skip to main content
Category: Access Control

Zero Trust

Also known as: ZT, Zero Trust Architecture, ZTA, Zero Trust Security Model
Simply put

Zero Trust is a security approach built on the principle of "never trust, always verify," meaning no user, device, or resource is trusted by default, even if it is already inside the network. Instead of relying on a fixed network perimeter, access is granted only after identity and other factors are verified for each request. It is intended to reduce risk by enforcing strict, least-privilege access controls.

Formal definition

Zero Trust is a security model that replaces static, perimeter-based defenses with dynamic, per-request access decisions grounded in least-privilege enforcement. Zero Trust Architecture (ZTA) applies these concepts across an enterprise cybersecurity plan, encompassing component relationships, workflow planning, and access policies, and is designed to minimize uncertainty when enforcing accurate access decisions. It dynamically secures users, devices, and resources, granting access only after verification rather than assuming trust based on network location. Note that Zero Trust is a set of concepts and an architectural approach, not a single product or control; its effectiveness depends on implementation, and it should be treated as complementary to, rather than a replacement for, other security and compliance requirements.

Why it matters

Traditional security models assumed that anything inside the network perimeter could be trusted, which left organizations exposed once an attacker gained a foothold or a legitimate credential was compromised. Zero Trust addresses this gap by removing implicit trust based on network location and requiring verification for each access request. For payment environments, where cardholder data and systems handling sensitive authentication data are frequent targets, reducing reliance on a static perimeter helps limit how far an attacker can move if one segment is breached.

Because Zero Trust enforces least-privilege, per-request access decisions, it is intended to shrink the blast radius of a compromise and make lateral movement more difficult. This aligns with the broader goal of restricting access to systems and data to only what is necessary. However, Zero Trust is a set of concepts and an architectural approach rather than a single product or control, and its effectiveness depends heavily on how it is implemented. It should be treated as complementary to, not a replacement for, existing security and compliance obligations such as PCI DSS.

Who it's relevant to

Security Engineers and Architects
Those designing enterprise defenses can use Zero Trust concepts to move beyond static perimeter models, structuring component relationships, workflow planning, and access policies around least-privilege, per-request verification. They should treat it as an architectural approach to be implemented and validated, not a product to be purchased.
Compliance Officers
Zero Trust can support access-control objectives, but it does not by itself satisfy any specific standard. Compliance teams should treat it as complementary to existing requirements such as PCI DSS and confirm that any controls implemented are validated against the current published standard rather than assuming the label alone demonstrates compliance.
Payment Processors and Acquirers
Organizations operating systems that handle cardholder data can apply Zero Trust to reduce implicit trust and limit lateral movement within their environments. Because effectiveness depends on implementation, these teams should verify how Zero Trust principles are applied to the specific workflows and access paths that touch sensitive data.
Merchant Risk and IT Operations Teams
Teams responsible for internal systems and remote access can use Zero Trust to enforce strict, least-privilege access even for users and devices already inside the network, helping reduce risk from compromised credentials or devices. Adoption is typically progressive and should be tailored to the organization's environment.

Inside ZT

Never trust, always verify
The core principle of Zero Trust: no user, device, or network segment is trusted by default, regardless of whether it sits inside or outside a traditional network perimeter. Access decisions are made continuously rather than granted once at a perimeter boundary.
Least privilege access
Users and systems are granted only the minimum access needed to perform a task. In a payment environment, this helps limit which accounts and services can reach systems that store, process, or transmit cardholder data, which may support scope reduction when properly implemented and validated.
Micro-segmentation
Dividing the network into granular zones so that access between workloads is controlled and inspected. This is distinct from, but can complement, PCI DSS network segmentation used to isolate the cardholder data environment; segmentation effectiveness must still be verified rather than assumed.
Strong identity and authentication
Continuous verification of identity, often using multi-factor authentication. Note that MFA addresses authentication of users and administrators and is a different control from EMV chip authentication, 3-D Secure, or strong customer authentication, which operate at other points in a transaction.
Continuous monitoring and verification
Access and device posture are re-evaluated over time rather than trusted after a single successful login. This supports detection but does not eliminate fraud or intrusion; monitoring controls carry false-positive and false-negative trade-offs.
Policy-based access enforcement
Access decisions are driven by dynamic policies that consider identity, device state, and context. These policies are enforced at the point of access rather than relying on network location as a proxy for trust.

Common questions

Answers to the questions practitioners most commonly ask about ZT.

Is Zero Trust a product I can buy to secure my payment environment?
No. Zero Trust is an architectural approach and set of design principles centered on never implicitly trusting a user, device, or network segment and continuously verifying each access request, rather than a single product or appliance. Vendors may sell tools that support Zero Trust objectives, but no purchase alone establishes the model. Implementing it requires policy, identity controls, segmentation, monitoring, and ongoing validation across your environment.
Does adopting Zero Trust make my organization PCI DSS compliant or replace the standard's requirements?
No. Zero Trust is not a compliance standard and does not substitute for PCI DSS validation. Some Zero Trust practices, such as strong access controls, least privilege, and network segmentation, can support outcomes that PCI DSS also addresses, but you must still validate against the specific requirements of the current published PCI DSS version. Requirement wording and numbering differ between versions, so confirm control mappings against the standard in force rather than assuming Zero Trust satisfies them.
How does Zero Trust relate to defining and reducing PCI DSS scope?
Zero Trust emphasizes granular segmentation and per-request verification, which can help isolate systems that store, process, or transmit cardholder data from those that do not. Effective segmentation may reduce the systems in scope for PCI DSS, but the scope reduction depends on how the controls are implemented and validated, not on the Zero Trust label. Scope determination should follow the current standard's guidance and be verified through appropriate testing.
How does multi-factor authentication fit into a Zero Trust implementation for payment systems?
Multi-factor authentication is one identity-verification control that supports the Zero Trust principle of verifying access requests, and it may mitigate credential-based access risks such as some account takeover scenarios. It is not the entirety of Zero Trust, which also relies on least privilege, device posture checks, continuous monitoring, and segmentation. MFA addresses access-time identity assurance and should not be assumed to eliminate fraud or replace transaction-level controls.
What role does continuous monitoring play in a Zero Trust deployment?
Continuous monitoring and logging support the principle of ongoing verification rather than one-time trust at login. In practice this means collecting access, device, and session signals to inform authorization decisions and detect anomalies. As with any detection-oriented control, monitoring involves false-positive and false-negative trade-offs, so tuning and analyst review are typically needed. Monitoring is intended to help detect and respond to suspicious activity, not to guarantee prevention.
How should Zero Trust be applied when protecting cardholder data versus sensitive authentication data?
Zero Trust access controls, least privilege, and segmentation can help restrict who and what may reach systems handling account data. This does not change the underlying data-handling rules: sensitive authentication data, such as full track data, card verification values, and PINs or PIN blocks, must not be stored after authorization even when encrypted, while some cardholder data such as PAN may be stored under defined controls. Zero Trust governs access to systems; it does not alter what data may be retained.

Common misconceptions

Zero Trust is a product you can buy and deploy.
Zero Trust is an architectural approach and set of principles, not a single product. It is implemented through a combination of identity, access control, segmentation, and monitoring practices, and its effect on any environment depends on implementation and validation.
Adopting Zero Trust makes an organization PCI DSS compliant or automatically reduces PCI DSS scope.
Zero Trust is not a PCI standard and does not by itself establish compliance. It may support controls such as least privilege and segmentation, but scope reduction depends on how the cardholder data environment is isolated and validated against the current published PCI DSS, not on the label 'Zero Trust.'
Zero Trust prevents fraud and breaches.
Zero Trust is intended to reduce the impact of compromised credentials and lateral movement, but it does not guarantee prevention of fraud or intrusion. It addresses access and network trust, and does not by itself address card-not-present fraud, account takeover at the payment layer, or other fraud types governed by separate controls and card brand rules.

Best practices

Define and enforce least privilege for all users, service accounts, and administrators that can reach systems storing, processing, or transmitting cardholder data, and review access regularly.
Use micro-segmentation to isolate sensitive workloads, and independently verify segmentation effectiveness rather than assuming it, especially where it is relied upon to reduce PCI DSS scope.
Require strong, continuously verified authentication such as multi-factor authentication for access to sensitive systems, recognizing this is separate from transaction-level controls like 3-D Secure or EMV.
Apply policy-based access decisions that consider identity, device posture, and context at the point of access rather than trusting network location.
Implement continuous monitoring and logging of access, and tune detection to manage false-positive and false-negative trade-offs.
Validate any Zero Trust-related controls against the current published PCI DSS requirements, confirming exact requirement numbering and wording rather than assuming a fixed reference.