PCI DSS 2.3.2: For wireless environments connected to the CDE or transmitting account data, wireless encryption keys are changed

Requirement 2: Apply Secure Configurations to All System Components › Section 2.3

For wireless environments connected to the CDE or transmitting account data, wireless encryption keys are changed as follows:

• Whenever personnel with knowledge of the key leave the company or the role for which the knowledge was necessary.
• Whenever a key is suspected of or known to be compromised.

Summary

Change wireless encryption keys when someone who knew the key leaves or changes role, and whenever a key might have been compromised.

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.3.2	Interview responsible personnel and examine key-management documentation to verify that wireless encryption keys are changed in accordance with all elements specified in this requirement.

This is event-driven, not periodic. There is no calendar here: the triggers are knowledge of the key leaving your control and suspicion or knowledge of compromise. Note that the trigger is knowledge of the key, not access to the network. Revoking someone's building pass does not un-know a pre-shared key they typed into their own phone. That is why the practical answer to this control is usually architectural rather than procedural, and it pairs with 2.3.1, which is about changing vendor defaults before the network carries anything.

What to prepare

• Key-management documentation naming who holds each wireless key and how a change is triggered.
• The leaver and role-change process, showing wireless keys as a step.
• A record of the last key change with the reason for it.

How to implement it

1. Move to 802.1X if you can, which removes the problem rather than managing it. With per-user authentication there is no shared key to rotate, so a leaver is handled by disabling their account and this control becomes trivially satisfiable.

2. If you are on a pre-shared key, know who has it. The obligation is to change the key when a knowledgeable person leaves, and you cannot act on that if the key was mailed round the office years ago.

3. Put the key change in the leaver checklist. HR triggers it, IT performs it. Left to memory it does not happen, and the assessor is interviewing the person who would have had to remember.

4. Write down what counts as suspicion. A device holding the key is lost, a contractor is dismissed, a key appears in a ticket. Deciding this in advance stops it being argued about after the event.

Where this commonly fails

• A pre-shared key shared so widely that changing it is treated as too disruptive, so it never changes.
• Rotating keys on a schedule and having no process for the two events the control actually names.
• Treating a role change as not a trigger, when the control names it alongside leaving.
• Key changes performed and not recorded, so there is nothing to examine.

Related controls

Others in section 2.3:

Control	What it requires
2.3.1	For wireless environments connected to the CDE or transmitting account data, all wireless vendor defaults are changed at installation or are confirmed to be secure, including but not limited…

---

← 2.3.1 · All controls · 3.1.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.