PCI DSS 1.4.5: The disclosure of internal IP addresses and routing information is limited to only authorized
PCI DSS v4.0.1 control 1.4.5: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 1.4.
Requirement 1: Install and Maintain Network Security Controls › Section 1.4
The disclosure of internal IP addresses and routing information is limited to only authorized parties.
Summary
Internal IP addresses and routing details are not handed out to anyone who has not been authorised to have them.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 1.4.5.a | Examine configurations of NSCs to verify that the disclosure of internal IP addresses and routing information is limited to only authorized parties. |
| 1.4.5.b | Interview personnel and examine documentation to verify that controls are implemented such that any disclosure of internal IP addresses and routing information is limited to only authorized parties. |
A control about disclosure, which is broader than any single mechanism and is why v4 states it as an outcome rather than prescribing address translation. The leaks are rarely in the firewall: internal hostnames in public DNS, internal addresses in application error pages and stack traces, mail headers, API responses, monitoring endpoints, and certificate transparency logs are all ways an internal topology becomes public without a rule permitting it. Note that the control does not forbid disclosure, it limits it to authorized parties, and 1.4.5.b interviews personnel and examines documentation about exactly that. So sharing routing detail with a partner is fine and needs to be authorised and recorded, which is the element entities have no artefact for.
What to prepare
- NSC configurations governing what is exposed externally.
- Any deliberate disclosure to a third party, with the authorisation for it.
- A check of what your public surface actually reveals: DNS, error pages, headers, API responses.
- The documentation 1.4.5.b examines for authorised disclosures.
How to implement it
1. Look at the application layer, not just the network. Verbose error pages and stack traces disclose more internal topology than most firewalls ever would.
2. Check public DNS for internal names. Records pointing at private addresses are a common and easily fixed leak.
3. Record the authorised disclosures. Partners and managed service providers often legitimately hold routing detail, and the control asks that this be limited to authorised parties rather than prevented.
4. Test from outside. What your public surface reveals is a question best answered by looking at it the way an outsider would.
Where this commonly fails
- Address translation treated as the whole control, while error pages disclose internal hosts.
- Internal hostnames in public DNS.
- Disclosure to a partner that is entirely reasonable and entirely undocumented, which fails 1.4.5.b.
- Monitoring or status endpoints exposed publicly, carrying internal addresses.
Related controls
Others in section 1.4:
| Control | What it requires |
|---|---|
| 1.4.1 | NSCs are implemented between trusted and untrusted networks |
| 1.4.2 | Inbound traffic from untrusted networks to trusted networks is restricted… |
| 1.4.3 | Anti-spoofing measures are implemented to detect and block forged source IP addresses… |
| 1.4.4 | System components that store cardholder data are not directly accessible from untrusted networks |
← 1.4.4 · All controls · 1.5.1 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.