Why dead control IDs keep turning up
SP 800-53 Rev. 5 was published in September 2020, and Rev. 4 control numbers are still everywhere: in system security plans, in control matrices copied from one project to the next, in vendor datasheets, and in last year’s audit responses. Most of them still point at something real. Some point at a stub. When an assessor reads “CM-6(3)” in your plan, they find a one-line note saying the enhancement was withdrawn, and your evidence for it now has to answer a different control.
This post lists the withdrawals a network or security team is most likely to meet, grouped by the work they touch, and how to clean up a mapping without carrying the old gaps into the new one.
How Rev. 5 retires a control
NIST doesn’t renumber the catalog when a control goes away. In its own words, “controls are not renumbered each time a control is withdrawn”, and withdrawn entries are “maintained in the control catalog for historical purposes.” It adds that “Control designations are not re-used when a control is withdrawn.” So an old ID never silently turns into something else. It turns into a stub.
The stub says one of two things. Incorporated into means the content was folded into another control, often a base control, where it may now sit as one example among several. Moved to means the enhancement kept its identity under a new number, usually in another family. A few stubs say something else: VoIP (SC-19) was dropped as “Technology-specific; addressed as any other technology or protocol.”
One more structural change catches people out. The Low, Moderate and High baselines are no longer in SP 800-53. The control baselines “have been relocated to NIST Special Publication 800-53B.” If your mapping says “required at Moderate per 800-53”, the reference needs updating even if the control ID is fine.
Boundary, flow and protocols
Most of the boundary material landed in SC-7. The old CA-3 system-connection enhancements kept their identities and moved into the boundary protection family, and three SC-7 enhancements were merged back into their parent.
Two of these change what you have to show. CA-3(5) now lives in SC-7(5), deny by default and allow by exception, which we cover in what SC-7(5) actually asks of a rule base. And turning off Telnet or cleartext management is no longer a remote-access enhancement: it sits under CM-7, least functionality, alongside every other port and protocol you’ve decided not to run.
Change, configuration and inventory
This group holds the withdrawal most control mappings get wrong. Unauthorized change detection used to be CM-6(3). It’s now part of SI-7, software, firmware and information integrity, and the review of system changes that used to be CM-5(2) is now CM-3(7).
The SI-7 move deserves a second look. The base SI-7 statement asks you to detect unauthorized changes to “organization-defined software, firmware, and information” and never mentions configuration. If you want it to cover firewall and switch configs, you have to name them in that parameter. We walk through it in a config snapshot is not a baseline.
Logging, time, access and monitoring
The audit family lost several enhancements to other families. Clock synchronization is the one that surprises people: it’s no longer an AU-8 enhancement at all, but SC-45(1) and SC-45(2) in system and communications protection.
The IA-2 change matters for network gear. The separate local, network and remote variants were merged, so multi-factor authentication for privileged accounts is now IA-2(1) whichever way the admin connects, console included. And logging settings on the devices themselves still fall under the audit family: we cover that in your syslog line is audit information.
Cleaning up a stale mapping
- Search for the old IDs. Go through the security plan, the control matrix, runbooks, vendor mapping tables and past audit responses. Search for the full enhancement form, such as
CM-6(3)orAU-8(1), since the base control usually still exists. - Map each one, then read the new control. “Incorporated into” can widen or narrow what you’re claiming. CM-6(3) was a narrow enhancement; SI-7 is a whole control with its own parameters and enhancements. Check that your evidence still answers the text you now cite.
- Carry the parameters over by hand. Values you set for the old enhancement, such as a review frequency or a list of components, don’t follow it automatically. Set them again on the new control, and check they don’t conflict with values already there.
- Fix baseline references and check the edition. Point baseline claims at SP 800-53B. This map comes from the PDF edition marked “INCLUDES UPDATES AS OF 12-10-2020”; NIST has issued catalog releases since, so confirm each entry against the current release before you rely on it.
Why we keep this map
SAMURAI runs compliance checks across your devices and exports a report per framework. Reports like that point at controls by number, so when the catalog withdraws or moves a control, the mapping behind them has to follow, the same way yours does. It isn’t a verdict: the organization sets the parameters, and an assessor decides whether a control is met. What a report can do is point at evidence under the right number, so nobody has to explain why it cites a stub. The firewall audit tool page covers what SAMURAI reads from each vendor, and the firewall audit checklist covers what an audit asks for.