PCI DSS 2.2.7: All non-console administrative access is encrypted using strong cryptography
PCI DSS v4.0.1 control 2.2.7: the requirement in full, the 4 testing procedures an assessor uses to verify it, and the related controls in section 2.2.
Requirement 2: Apply Secure Configurations to All System Components › Section 2.2
All non-console administrative access is encrypted using strong cryptography.
Summary
Every administrative session that is not at the physical console is encrypted with strong cryptography.
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 | |
|---|---|
| 2.2.7.a | Examine system configuration standards to verify they include encrypting all non-console administrative access using strong cryptography. |
| 2.2.7.b | Observe an administrator log on to system components and examine system configurations to verify that non-console administrative access is managed in accordance with this requirement. |
| 2.2.7.c | Examine settings for system components and authentication services to verify that insecure remote login services are not available for non-console administrative access. |
| 2.2.7.d | Examine vendor documentation and interview personnel to verify that strong cryptography for the technology in use is implemented according to industry best practices and/or vendor recommendations. |
Four testing procedures for one sentence, which is a signal about how thoroughly it is checked: the policy, the configurations, an observation of an administrator logging in, and a check that insecure protocols are not merely deprioritised but unavailable. That last point is the one that fails: leaving Telnet or unencrypted HTTP listening as a fallback means an administrator can still use it, and a service that accepts a plaintext login is what the procedure looks for. Pairs with 8.4.1: strong authentication over a plaintext channel protects the password only until someone reads it off the wire.
What to prepare
- The list of administrative access methods per system component.
- Configuration evidence that plaintext protocols are disabled, not just unused.
- Evidence of the cipher suites and protocol versions in use for those sessions.
How to implement it
1. Disable, do not deprioritise. A listening Telnet or HTTP management port is available whether or not anyone is meant to use it, and the procedure examines services rather than habits.
2. Include the devices that are not servers. Switches, printers, appliances and out-of-band management cards frequently ship with plaintext management enabled and are administered rarely enough that nobody notices.
3. Check the crypto, not just the protocol name. SSH and HTTPS both admit weak configurations, and "encrypted" is not the requirement: strong cryptography is.
4. Watch the fallbacks. A management interface that redirects HTTP to HTTPS still accepted the credential over HTTP if the client sent it there first.
Where this commonly fails
- Telnet or HTTP left listening as a backup path.
- Network appliances and out-of-band management excluded from the review.
- Strong protocol, weak cipher suite, which the configuration examination catches.
- Redirects treated as protection, when the plaintext request happened first.
Related controls
Others in section 2.2:
| Control | What it requires |
|---|---|
| 2.2.1 | Configuration standards are developed, implemented, and maintained… |
| 2.2.2 | Vendor default accounts… |
| 2.2.3 | Primary functions requiring different security levels… |
| 2.2.4 | Only necessary services, protocols, daemons, and functions are enabled… |
| 2.2.5 | If any insecure services, protocols, or daemons are present… |
| 2.2.6 | System security parameters are configured to prevent misuse |
← 2.2.6 · All controls · 2.3.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.