Who is accountable when third-party access into the CDE still uses legacy MFA?

The organisation operating the cardholder data environment remains accountable for the access path, even when a vendor or contractor is involved. PCI DSS 4.0 expects remote and third-party access to meet the same authentication discipline as internal access. Teams should assign ownership for every exception and review it as a formal risk decision.

Why This Matters for Security Teams

Legacy MFA on third-party access into the CDE is not a vendor problem alone. The cardholder data environment owner still owns the risk, because PCI scope follows the access path, not the employment status of the person using it. When third parties use older authentication flows, the organisation must prove that access is controlled, reviewed, and limited to the business need. That expectation is consistent with the direction of the OWASP Non-Human Identity Top 10 and the governance themes in the Ultimate Guide to NHIs.

The practical risk is that legacy MFA often persists as an exception long after the original justification has expired. That creates blind spots in identity assurance, session control, and offboarding. If a contractor account is compromised, the attacker inherits the same path into the CDE, and the control failure is attributed to the environment owner, not the external user. NIST also treats authentication and access control as core system responsibilities, not optional vendor choices. In practice, many security teams encounter this only after a payment-path exception has already been approved and forgotten.

How It Works in Practice

Accountability starts with ownership of the access route. The organisation must maintain a register of every third-party path into the CDE, identify the business owner, and document the compensating control if legacy MFA is still in place. That includes whether the access is interactive, remote-admin, API-driven, or brokered through a jump host. For PCI-oriented environments, the question is not whether the vendor can authenticate, but whether the authentication method meets the organisation’s standard and is reviewed as a time-bound exception.

Effective control usually combines identity proofing, session restrictions, and continuous review. At minimum, teams should map who can approve access, who can attest to necessity, and who can revoke it. If the access depends on a service account or shared credential, the risk increases further because the control is no longer tied to a named person. The Ultimate Guide to NHIs — Key Challenges and Risks highlights how exposed third-party relationships and excessive privileges amplify this pattern. NIST SP 800-53 Rev. 5 also reinforces the need for access enforcement, authentication, and accountability through controls such as AC and IA families.

• Assign a business owner for every third-party CDE access path.
• Record the authentication method, exception rationale, expiry date, and compensating control.
• Review whether legacy MFA is tied to a person, a shared account, or a service credential.
• Reassess access after vendor changes, incidents, or contract renewal.

Where teams get it wrong is treating the vendor’s login method as outside their scope, when the environment owner still has to prove the control works end to end. These controls tend to break down when third-party access is shared, inherited through nested suppliers, or left in place for emergency support without a formal expiry date.

Common Variations and Edge Cases

Tighter third-party access controls often increase operational friction, so organisations have to balance incident response speed against authentication assurance. That tradeoff becomes visible when a vendor insists on legacy MFA to preserve remote support, but the CDE owner needs stronger assurance for every privileged session. Current guidance suggests that exceptions can be accepted only when they are explicitly owned, time-boxed, and monitored.

Edge cases usually involve inherited access, where a prime supplier subcontracts support, or break-glass access, where legacy MFA appears only during outages. In both cases, accountability still sits with the CDE operator because the organisation chose to permit the access path. The broader NHI research base shows why this matters: NHIs are exposed to third parties at scale, and the attack surface grows quickly when access is not formally retired. That is why the operational question is not who supplied the tool, but who approved the exception, who is watching it, and who can remove it when the risk changes.

There is no universal standard for this yet, but best practice is evolving toward stronger identity assurance, short-lived access, and documented exception governance rather than permanent legacy MFA tolerance. Teams should also track any third-party exceptions alongside the wider NHI inventory so the access path is visible during audits and incident response.

Related resources from NHI Mgmt Group

• Who is accountable when third-party or service access is still routed through a VPN?
• Who is accountable when third-party remote access is overused in public safety environments?
• Who is accountable for third-party access after a campaign or project ends?
• Who is accountable when a user grants a risky third-party app access?