PCI DSS internal penetration testing now spans cloud and build pipelines

At a glance

What this is: PCI DSS internal penetration testing now has to account for cloud, SaaS, and deployment pipelines as in-scope paths into the CDE.

Why it matters: IAM, PAM, and security teams need to validate that credential theft, session reuse, and build-pipeline access cannot bypass segmentation and reach cardholder data.

👉 Read Bishop Fox's guide to PCI DSS internal penetration testing and scoping

Context

PCI DSS internal penetration testing is no longer a pure network exercise. The scoping problem now includes cloud infrastructure, SaaS applications, and deployment systems that can affect the cardholder data environment, which means identity and access controls have become part of the test surface as much as routing and segmentation.

That matters because many real-world paths into sensitive environments begin with credentials, sessions, or pipeline access rather than a direct network exploit. For identity teams, the control question is whether authentication, authorization, and privileged access boundaries still hold when the attacker already has a legitimate-looking path into adjacent systems.

Key questions

Q: What fails when PCI segmentation is tested only at the network layer?

A: Network-only testing misses the most common bypass route: authenticated access. If a user account, session, or pipeline identity can still reach the CDE through a trusted application or cloud service, the boundary has not actually held. Effective PCI testing has to prove that credentialed access cannot cross into cardholder-data systems even when ports look closed.

Q: Why do cloud and SaaS identities matter in PCI DSS internal testing?

A: Because cloud tenants, SaaS platforms, and their administrative identities can control, store, or expose systems that touch the CDE. Once those identities are in scope, access reviews, privilege design, and session controls become part of PCI segmentation evidence. A firewall may block traffic, but identity can still create a functional path into protected data.

Q: How should security teams test build pipelines in PCI environments?

A: They should treat pipelines as privileged identities that can alter production-adjacent systems. That means validating who can trigger workflows, which secrets the pipeline can read, whether artifacts can be modified, and whether the pipeline can reach systems that impact the CDE. If a workflow compromise can deploy into the PCI boundary, the pipeline is in scope.

Q: Who is accountable when segmentation fails because of identity abuse?

A: Accountability sits with the environment owner, the identity governance team, and the assessor responsible for confirming scope and control effectiveness. PCI DSS requires the organisation to document what is in scope and prove segmentation works as intended. If identity paths are ignored, the failure is usually a governance gap, not only a technical one.

Technical breakdown

How PCI DSS scoping now pulls cloud identity into IPT

PCI DSS v4.0.1 makes internal penetration testing more expansive by treating cloud components, SaaS applications, and software deployment systems as part of the environment that can impact the CDE. That changes the test from simple subnet validation to a broader assessment of where cardholder data flows, where trust boundaries exist, and which services can indirectly influence access to protected data. If a cloud tenant, SaaS app, or CI/CD pipeline can alter, store, or expose systems connected to the CDE, it belongs in the scoping conversation.

Practical implication: build IPT scope around identity-bearing systems and deployment paths, not just network segments.

Why authentication and authorization belong in segmentation testing

Segmentation is often described as a network control, but PCI testing has to examine whether an attacker can cross the boundary by using valid credentials. If a user can log into a SaaS platform, internal service, or workstation and then reach cardholder data or an adjacent workload, the segmentation model may be functionally weak even when ports look closed. This is where IAM and PAM intersect directly with PCI scope: access paths created by credentials, sessions, and over-permissioned identities can matter more than open network routes.

Practical implication: test for credential-based reachability into the CDE, not only IP-based reachability.

Why build pipelines are now part of the attack path

Deployment systems such as GitHub Actions, Azure DevOps, Jenkins, and similar tools can become indirect entry points if an attacker can inject code, abuse stored secrets, or alter the workflow that pushes objects into the CDE. PCI DSS now recognises that software delivery is part of the control plane, not just an engineering convenience. If a pipeline can deploy compromised artifacts, expose credentials, or modify cloud resources, it can create a path that bypasses otherwise strong perimeter segmentation.

Practical implication: include CI/CD identity, secrets, and workflow integrity in every internal segmentation test.

Threat narrative

Attacker objective: The attacker wants a legitimate-looking path into the cardholder data environment that bypasses segmentation and reaches cardholder data or the systems that protect it.

1. Entry occurs when an attacker gains access through exposed credentials, a SaaS login, or a compromised deployment workflow that can touch systems near the CDE.
2. Escalation follows when the attacker uses legitimate access paths, reusable sessions, or over-permissioned identities to move from adjacent systems into the cardholder data boundary.
3. Impact occurs when segmentation fails to stop reachability to CHD, allowing data exposure, unauthorized system access, or further lateral movement inside the CDE.

NHI Mgmt Group analysis

PCI scoping is now an identity problem as much as a network problem. The article reflects a wider shift in which cloud tenants, SaaS applications, and deployment pipelines can no longer be treated as peripheral to segmentation. For identity practitioners, that means the boundary between IAM, PAM, and PCI testing is thinner than many governance models assume. If a credential or session can bridge into the CDE, segmentation is only as strong as the identity path feeding it.

Authentication-based segmentation failure is the control gap this post exposes. Many organisations still equate segmentation with firewall policy, but the practical failure mode is an authenticated user reaching protected data through a trusted service or shared access path. That is the kind of issue PCI DSS testing is designed to expose. The lesson is not simply to add more controls, but to challenge whether current access design actually blocks meaningful attacker movement.

Build pipelines are becoming part of the CDE trust boundary. When software delivery systems can deploy into, configure, or influence cardholder-data environments, their identities and secrets inherit PCI relevance. This is where NHI governance becomes critical, because pipeline tokens, service accounts, and automation credentials often have broader reach than human users. The practitioner takeaway is clear: treat pipeline identity as an in-scope control surface, not a back-end implementation detail.

Named concept: credential-mediated segmentation bypass. This article describes the failure mode where a valid credential, reusable session, or over-permissioned identity provides the attacker with a route that network segmentation was never designed to stop. That concept matters because it reframes segmentation from a perimeter question to an identity assurance question. Practitioners should test whether access paths remain blocked after credentials, sessions, and deployment identities are accounted for.

PCI DSS testing is now validating trust assumptions across multiple control layers. The strongest reading of this guidance is that organisations must prove their environment resists not just scanning and lateral movement, but also legitimate access abuse and pipeline compromise. That aligns with NIST-CSF PR.AC and OWASP-NHI principles around least privilege and credential governance. The operational conclusion is to test the whole trust chain, from identity issuance to CDE reachability.

What this signals

Credential-mediated segmentation bypass will keep showing up anywhere organisations rely on identity boundaries but test only network controls. For PCI programmes, the practical signal is that IPS, firewall, and scanner results are no longer enough on their own. Teams should expect assessors and red teams to ask whether a valid user, service account, or build token can still reach the CDE through a trusted path.

The identity lesson extends beyond PCI. Where automation, cloud tenants, and SaaS workflows carry privileged access, scope decisions need to include the identities that operate those systems, not only the systems themselves. That is why the access model behind the workload matters as much as the workload location, especially when organisations are trying to prove that segmentation is effective in practice.

The governance pattern is consistent with the broader NHI problem: once access is distributed across humans, bots, pipelines, and service accounts, security teams need evidence that each identity can be contained at the point of use. That is where the alignment with the 52 NHI Breaches Analysis becomes useful for programme planning, because the failure mode is almost always excessive trust in a credentialed path.

For practitioners

• Map CDE reachability through identity paths Document every login, token, service account, and session that can reach systems near the CDE, including SaaS and cloud admin paths. Use that inventory to define which paths must be exercised during IPT scoping and which should be treated as out-of-scope only after proof, not assumption.
• Include CI/CD identities in penetration scope Treat GitHub Actions, Azure DevOps, Jenkins, and similar systems as part of the attack surface when they can deploy into or modify systems connected to the CDE. Test workflow permissions, stored secrets, artifact integrity, and whether pipeline credentials can be reused outside the intended build context.
• Test authentication segmentation, not just network segmentation Validate whether a stolen account, reused session, or over-permissioned role can reach CHD through internal apps, SaaS tools, or shared services even when direct network routes are blocked. If credentialed access defeats the boundary, the segmentation model is incomplete.
• Separate QSA evidence from exploitability evidence Capture both the scoping spreadsheet required by PCI and the practical proof that a service is reachable or exploitable from each tested segment. Include the exact network segment, IPs, and ports, then show whether credentials, pipelines, or sessions changed the outcome.

Key takeaways

• PCI DSS v4.0.1 turns internal penetration testing into a broader identity and cloud scoping exercise, not just a network test.
• The main failure mode is credential-mediated segmentation bypass, where legitimate access paths reach the CDE despite network controls.
• Security teams should include cloud, SaaS, and CI/CD identities in scope and prove that those paths cannot reach cardholder data.

Key terms

• Credential-Mediated Segmentation Bypass: A failure mode where valid credentials, sessions, or delegated access let an attacker cross a segmentation boundary that network controls were expected to enforce. The problem is not the absence of a login, but the presence of a trusted path that still reaches protected systems or data.
• Cardholder Data Environment: The cardholder data environment is the set of systems, users, and processes that store, process, or transmit payment card data. For NHI governance, it includes every machine identity that can influence those systems, even when the identity itself is invisible to end users.
• Segmentation Control: Any technical or administrative measure intended to prevent one environment from reaching another without explicit approval. In PCI testing, this includes firewalls, identity controls, session boundaries, cloud restrictions, and deployment paths, because each can determine whether an attacker can move into the CDE.
• In-Scope System Component: A system, service, or software element that must be included in PCI DSS scoping because it stores, processes, transmits, or can affect cardholder data. Under v4.0.1, that can include cloud infrastructure, SaaS applications, and build pipelines, not only traditional on-premises assets.

What's in the full article

Bishop Fox's full post covers the operational detail this post intentionally leaves for the source:

• The scoping inputs used to map cardholder-data flows, segmentation boundaries, and third-party connections.
• The practical spreadsheet structure used to document tested segments, IP addresses, and open ports.
• The differences between an IPT report and a segmentation findings report for QSA review.
• The kinds of environments Bishop Fox uses to test from, including internal VMs, appliances, and compromised pods.

👉 The full Bishop Fox post covers scoping inputs, segmentation testing detail, and deliverable structure.

Deepen your knowledge

NHI Mgmt Group's NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It is designed for practitioners building access control and governance models that must withstand cloud, automation, and identity sprawl.