Zero trust has been sold hard enough that the term now carries almost no information. It is worth returning to the source: NIST SP 800-207 describes an architecture in which trust is never granted implicitly by network position, access decisions are made per request against policy, and the decision is enforced as close to the resource as possible. Nothing in that description names a product.
For a payment processor the model is a good fit, because the historical architecture — a hardened perimeter around a flat internal network carrying card data, settlement systems and merchant configuration — is precisely the design zero trust was articulated against. What follows is what the model actually requires, and a migration order that does not involve rebuilding the estate.
The three components that matter
SP 800-207 separates the policy engine (decides), the policy administrator (issues or revokes the session) and the policy enforcement point (sits in front of the resource). Whatever tooling you use, be able to point at each of these in your own architecture and say which component performs the role.
The common failure is a design with enforcement points and no coherent policy engine: each service enforces its own rules from its own configuration. That is not zero trust; it is the same distributed authorisation drift that produced the problem, with new terminology applied.
Identity for workloads, not just people
User identity in payment processors is usually adequate — federated authentication, multi-factor, conditional access. Workload identity is usually not. Services authenticate to each other with long-lived shared secrets, or with nothing at all because they sit inside the same network segment.
This is where a migration should start, because it produces immediate risk reduction and it is a prerequisite for everything else. Concretely: every service gets a cryptographic identity issued by a workload identity system with short-lived credentials, mutual TLS between services with certificate-based identity, and authorisation decisions made against the calling workload identity rather than the source address.
The measurable outcome is that an attacker with a foothold on one host can no longer reach the settlement service simply because the host is on the right network.
Per-request decisions, with real inputs
A per-request access decision is only as good as the signals feeding it. Useful inputs for a payment processor include the authenticated identity and its assurance level, device posture for human access, the sensitivity classification of the resource, the action requested, and current threat signals. Decisions should be re-evaluated during a session, not only at establishment: a session that started from a compliant device and a normal location should not remain authorised after either changes.
Keep the policy expressible and reviewable. Policy that only exists as accumulated configuration across a dozen enforcement points cannot be audited, and an auditor will ask to see it.
Segmentation that reflects the data
Microsegmentation is frequently implemented as smaller network zones, which reproduces the original model at higher cost. The useful version is segmentation by data sensitivity and function, enforced by identity-aware policy rather than by address.
For a payment processor the segments worth defining are the cardholder data environment, the settlement and clearing path, merchant configuration, customer support tooling, and analytics and reporting. The property to enforce is that each segment's services accept calls only from named workload identities performing named operations, with everything else denied by default and logged.
This has a direct PCI DSS benefit worth stating explicitly: identity-based segmentation that is verifiable and tested constitutes evidence for scope reduction in a way that a firewall rule set with accumulated exceptions does not.
Where the vendor pitch and the standard diverge
Three claims deserve scepticism.
"Zero trust means no VPN." Replacing a VPN with an identity-aware proxy for human access to internal applications is a genuine improvement and usually the most visible early win. It addresses one access pattern. Service-to-service traffic, which is most of the traffic in a payment platform, is untouched by it.
"Zero trust is a product." It is an architectural property. Any single product implements a component. The integration and the policy model are the work, and they are not purchasable.
"Zero trust removes the need for network controls." Egress filtering, network monitoring and boundary controls remain valuable. Zero trust removes implicit trust from network position; it does not remove the value of knowing what your network is doing, and a supervisor will still ask.
A migration order that works
Sequencing matters more than tooling choice. The order that produces value earliest and avoids rework:
- Inventory. Services, data flows, existing trust relationships. You cannot write per-request policy for services you cannot enumerate.
- Workload identity. Cryptographic identity and short-lived credentials for every service. Removes the shared-secret layer that underpins lateral movement.
- Human access. Identity-aware access to internal applications, replacing flat network access. Visible, self-contained, good early demonstration.
- Service authorisation. Per-call authorisation against workload identity, starting with the highest-sensitivity segment — settlement and cardholder data.
- Policy consolidation. Move scattered enforcement configuration into a reviewable policy model with a single source of truth.
- Continuous evaluation. Signals, re-evaluation during sessions, revocation that takes effect promptly rather than at token expiry.
Each step stands alone and improves the position whether or not the next one happens. That property is what makes the model adoptable in a processor that cannot pause its roadmap for an architectural programme, and it is the reason we recommend judging progress by which of these steps is complete rather than by whether the estate has been declared zero trust.
