Hire by Technology
SERVICES
Contents
Share this article
Key Takeaways
Under PCI DSS v4.0.1, Requirement 8.4.2 makes MFA mandatory for all access into the cardholder data environment, admin or not, remote or local.
But MFA isn't required where remote access reaches only a properly segmented, non-CDE network.
For many companies, segmenting their developers out of scope is a useful strategy to minimize compliance requirements.
Let’s look at all the intricacies of PCI DSS access control for remote developers, so you can make the best decisions for your firm specifically, whether you are outsourcing software development, utilizing staff augmentation, or hiring remote, in-house developers.
For more information on your specific situation, and to connect with developers who have real production experience with a variety of regulations, talk to an expert.
Anyone still working from v3.2.1 needs to recalibrate first. PCI DSS v4.0.1 is the version in force now.
It's a limited, clarification-only revision of v4.0, published June 11, 2024, and it became the sole active standard once v4.0 itself retired on December 31, 2024.
As of March 31, 2025, the 51 requirements v4.0 introduced back in 2022 as "future-dated" started being mandatory. There's no grace period left to lean on.
The recent change that’s affecting most people is that requirement 8.4.2 extends MFA to all access into the CDE. Under the old standard, admin access and remote access were two separate problems you could reason about independently.
For many companies, this means the cost of having a developer in scope just went up, so the highest-value decision is keeping as many of them out of scope as the architecture allows.
The CDE is every system that stores, processes, or transmits cardholder data, plus anything connected to those systems or capable of affecting their security if compromised.
Requirement 12.5.2 requires confirming that scope at least once every 12 months, or after any significant change, by identifying every account data flow and every connected or impacting system.
Scope, in other words, is contagious. A laptop with a network path into the CDE is in scope. A CI runner that can deploy into the CDE is in scope. A jump box used to reach the CDE is in scope too.
This is different from SOC 2 access control, which is procedural. Was access approved, reviewed on schedule, and revoked when it should have been, with evidence to show for it?
Under PCI DSS, you can avoid costs by splitting your developers into three tiers, allowing you to collapse the real control burden into the smallest group you can defend.
| Tier | Definition | What Applies |
| 1. Out of scope | No network path to the CDE, no ability to deploy into it, no access to anything that could impact it | Essentially none of Requirement 8's MFA-into-the-CDE obligations |
| 2. Connected systems | No direct CDE access, but a path that could impact it (shared CI/CD, a logging or auth server the CDE depends on) | Least privilege and RBAC, plus authentication requirements |
| 3. CDE access | Genuinely needs to reach systems that store, process, or transmit cardholder data | Full weight: MFA, unique IDs, documented least privilege |
This is where most of an engineering org should sit.
These developers have no network path to the CDE, no ability to deploy into it, and no access to anything that could impact its security if compromised. This means working on product surfaces that never touch a primary account number at all.
Normal security posture still holds, obviously, but Requirement 8's MFA-into-the-CDE obligations simply don't reach a developer who has no path to the CDE in the first place.
To get here takes real architecture. Validated network segmentation is the foundation, paired with a design that keeps card data out of your systems from the start.
Good examples of this include tokenization, hosted fields, or an iframe so the PAN never lands on your own servers, and a vault or gateway holding whatever sensitive data genuinely needs to exist somewhere.
Once set up, this segmentation has to be validated through testing. An untested boundary won’t be accepted by a QSA, so make sure to budget for it.
This tier has no direct CDE access, but it has a path that could impact the CDE, and that's enough to pull it into scope.
Think of things like shared CI/CD that can deploy to CDE targets, or a logging or authentication server the CDE depends on.
Because these systems are in scope, Requirement 7's need-to-know and least-privilege rules apply to who can use them, along with the relevant authentication requirements.
This is also the tier where most teams accidentally end up.
The single most common mistake we see here is a shared CI pipeline. One runner that deploys both the marketing site and the payment service pulls every engineer with pipeline access into scope, including the ones who've never touched a payments feature in their life.
Splitting the pipeline is almost always cheaper than trying to control the entire population with access to it.
This tier genuinely needs to reach systems that store, process, or transmit cardholder data, and it should stay small on purpose.
Here's what applies, in full:
Keep in mind that v4.0.1's applicability notes for Requirement 8 allow a phishing-resistant authentication factor, a hardware-backed passkey or certificate-based authentication, to substitute for MFA on non-administrative CDE access.
The exact conditions attached to this are specific enough, and different sources number the sub-requirement differently enough, that it's worth verifying against the current standard directly.
Practically, you should keep Tier 3 to a named, small, regularly reviewed group, time-boxed and individually justified.
Requirement 8.4.3 covers remote access originating from outside your network, and its own applicability notes state the exemption plainly: MFA isn't required where that remote access reaches only a part of the network that's properly segmented from the CDE.
Instead, MFA is required where the access leads to, or could lead to, the CDE itself.
This is essentially a design instruction, since every part of Requirement 8 touching remote access is conditional on reachability.
When you change what a connection can reach, the requirements attached to whoever's making that connection change with it, ultimately, this is a network architecture decision, and should be owned by whoever runs your platform.
Four levers actually move this, roughly in order of what they tend to cost:
None of this is free, and it isn't universally possible either. If you're an issuer, a processor, or building your own card vault, someone has to sit inside the CDE, and no amount of clever segmentation removes that.
What you can do is make the group small, well-documented, and tightly controlled.
A handful of items apply regardless of which tier a developer sits in.
You should never have shared or generic accounts. Something like "contractor-01" fails Requirement 8's identification criteria outright.
No live cardholder data in development or test environments will fly either.
This is where outsourced teams get caught most often. A production data dump pulled in for debugging can quickly turn what should be a Tier 1 developer into a live CDE incident. Synthetic or de-identified data, enforced technically rather than by policy alone, is the fix.
Access follows the individual, not the vendor. One named human, tied to one identity, that you could point to by name in front of an assessor if you had to.
Least privilege is a documented role definition. Requirement 7 expects role-based access that's actually recorded somewhere.
Similarly, scope actually needs to get re-confirmed. Requirement 12.5.2 makes that validation a recurring obligation, at least annually.
Finally, even when you are hiring with urgency, you need to keep in mind that background checks and training attestations apply before day one.
Whether the engineer is internal or comes through a staffing partner, the timing is the same.
Two things change when the engineers touching any of this are external. The first is the responsibility matrix.
Requirement 12.8 governs how third-party service providers get managed, and it includes a specific expectation, 12.8.5, that responsibilities get documented and confirmed: which PCI DSS requirements you own, which the vendor owns, and which are genuinely shared.
Questions worth settling before an engagement starts include:
The second is whose equipment and whose identity are actually in the loop.
A vendor-managed laptop connecting to a Tier 2 or Tier 3 system means a device you don't control has just entered scope.
For most fintechs, the workable pattern is some combination of your identity provider, your device posture requirements, or a virtual desktop that keeps the physical endpoint out of scope regardless of whose laptop it technically is.
The thing you need to keep in mind here is that a compliant vendor doesn't reduce your scope. Your architecture does.
The better move is designing the engagement so external engineers sit in Tier 1, working on product surfaces that never touch cardholder data, and keeping Tier 3 small, internal, and tightly held.
That's a staffing-and-architecture decision made before anyone signs anything.
Trio's engineers work inside your identity provider, your device requirements, and whatever scope boundary you define, at $40 to $80 an hour, all-in, with placement usually running three to five days.
Expertise
Subscribe to our newsletter
Related
Content
Continue Reading
