PCI DSS 3.5.1.3: If disk-level or partition-level encryption is used
PCI DSS v4.0.1 control 3.5.1.3: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 3.5.
Requirement 3: Protect Stored Account Data › Section 3.5
If disk-level or partition-level encryption is used (rather than file-, column-, or field-level database encryption) to render PAN unreadable, it is managed as follows:
- Logical access is managed separately and independently of native operating system authentication and access control mechanisms.
- Decryption keys are not associated with user accounts.
- Authentication factors (passwords, passphrases, or cryptographic keys) that allow access to unencrypted data are stored securely.
Summary
Where disk encryption is used, unlocking it must not be the same as logging in.
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 | |
|---|---|
| 3.5.1.3.a | If disk-level or partition-level encryption is used to render PAN unreadable, examine the system configuration and observe the authentication process to verify that logical access is implemented in accordance with all elements specified in this requirement. |
| 3.5.1.3.b | Examine files containing authentication factors (passwords, passphrases, or cryptographic keys) and interview personnel to verify that authentication factors that allow access to unencrypted data are stored securely and are independent from the native operating system’s authentication and access control methods. |
The control that makes disk encryption mean something. Three elements and they describe one idea: the disk must not unlock as a consequence of ordinary operating system authentication. Logical access is managed separately and independently of native operating system authentication and access control mechanisms, decryption keys are not associated with user accounts, and the authentication factors that allow access to unencrypted data are stored securely. If a domain account unlocks the volume, then compromising that account compromises the data, and the encryption has added a step rather than a boundary. It pairs with 3.5.1.2: that control says when disk encryption is sufficient, and this one says how it must be managed whenever it is used at all.
What to prepare
- How the encrypted volume is unlocked, and by what credential.
- Evidence that the unlocking credential is not an operating system account.
- Where the authentication factors or keys are stored, which 3.5.1.3.b examines directly.
- The observed authentication process, which 3.5.1.3.a requires.
How to implement it
1. Unlock from something the operating system does not own. A hardware module, a key management service, or a separate credential store keeps the boundary real.
2. Never store the key on the volume it protects, or in a file beside it. 3.5.1.3.b examines files containing authentication factors, and this is what it is looking for.
3. Keep decryption keys off user accounts. A key tied to an administrator's login makes that login equivalent to the data.
4. Be able to demonstrate the unlock. The first procedure observes the authentication process, so it is shown rather than described.
Where this commonly fails
- Volumes unlocking automatically on boot from a key file on the same host.
- Domain credentials granting both system access and decryption.
- The recovery key stored in a document store any administrator can read.
- Encryption managed entirely within the operating system, which is what the first element rules out.
Related controls
Others in section 3.5:
| Control | What it requires |
|---|---|
| 3.5.1 | PAN is rendered unreadable anywhere it is stored by using any of the following approaches… |
| 3.5.1.1 | Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) are keyed… |
| 3.5.1.2 | If disk-level or partition-level encryption… |
← 3.5.1.2 · All controls · 3.6.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.