The additions, merges, splits, moves, and withdrawals between the two revisions — each with what an implementer and a documentation owner do about it. Requirements that carried over one-to-one are not listed; every requirement page names its own counterparts.
NIST publishes its own analysis of changes as supplemental material on the Rev. 3 publication page, and that material is authoritative for what changed. This page is an independent working summary, authored against the primary publications and awaiting an SME verification pass. Where the two disagree, the official analysis wins — verify before acting on any single row. Updated 2026-08-06.
| Rev. 2 family | Rev. 3 family | What moved |
|---|---|---|
| 3.1 Access Control | 03.01 Access Control | Six requirements consolidated into broader parents (remote access, wireless, mobile, external systems). |
| 3.2 Awareness and Training | 03.02 Awareness and Training | Insider-threat awareness folded into literacy training. |
| 3.3 Audit and Accountability | 03.03 Audit and Accountability | Restructured: event logging, record content, and generation become explicit requirements. |
| 3.4 Configuration Management | 03.04 Configuration Management | Component inventory, information location, and high-risk-travel configuration become standalone requirements. |
| 3.5 Identification and Authentication | 03.05 Identification and Authentication | Password requirements consolidated and modernized; authenticator management added. |
| 3.6 Incident Response | 03.06 Incident Response | Incident response training and a written plan become standalone requirements. |
| 3.7 Maintenance | 03.07 Maintenance | Reduced to tools, nonlocal sessions, and personnel; routine perform-maintenance expectations recategorized. |
| 3.8 Media Protection | 03.08 Media Protection | Transport encryption folds into transport; ownerless-media rule folds into media use. |
| 3.9 Personnel Security | 03.09 Personnel Security | Carried forward with organization-defined parameters. |
| 3.10 Physical Protection | 03.10 Physical Protection | Visitor, logging, and access-device rules consolidated; transmission-line access added. |
| 3.11 Risk Assessment | 03.11 Risk Assessment | Remediation folds into monitoring and scanning; risk response added. |
| 3.12 Security Assessment | 03.12 Security Assessment and Monitoring | Renamed; the system security plan moves to the new Planning family; information exchange added. |
| 3.13 System and Communications Protection | 03.13 System and Communications Protection | Transmission and at-rest confidentiality merge; several technology-specific requirements retire into boundary protection. |
| 3.14 System and Information Integrity | 03.14 System and Information Integrity | Malicious-code updates and scanning fold into one requirement; monitoring absorbs unauthorized-use identification; information retention added. |
| — | 03.15 Planning | New family: policies and procedures, the system security plan, rules of behavior. |
| — | 03.16 System and Services Acquisition | New family: security engineering, unsupported components, external system services. |
| — | 03.17 Supply Chain Risk Management | New family: SCRM plan, acquisition strategies, supply chain requirements and processes. |
New in Rev. 3 with no Rev. 2 counterpart requirement.
Information Location: identify and document where CUI is processed and stored, and who has access there.
CUI discovery and location tracking becomes explicit work rather than an implied by-product of scoping — a real lift for organizations that never mapped their data.
The system boundary worksheet and CUI applicability questionnaire produce exactly this record; keep them current.
System and Component Configuration for High-Risk Areas: issue hardened configurations for travel to high-risk locations and examine equipment on return.
If your people travel internationally with devices, you need a loaner/hardening procedure and a return-inspection step. If they do not, document the non-applicability deliberately.
A short travel-device procedure and a per-trip record.
Authenticator Management: issuing, protecting, and revoking authenticators — passwords, keys, certificates, tokens — across their lifecycle.
The lifecycle around authenticators (who gets a key, how defaults are changed, how loss is handled) becomes assessable, which formalizes what good MFA rollouts already do.
An authenticator-lifecycle section in the identity standard; issuance and revocation records as evidence.
Incident Response Training: train personnel in their incident response roles on a defined cadence.
Role-specific IR training — not just awareness — with a cadence you declare and keep.
Add IR rows to the training matrix; retain completion records per role.
Incident Response Plan: a written, maintained, distributed plan becomes its own requirement rather than an implied part of the capability.
The plan document itself is now checkable: current, distributed to the people named in it, and updated after lessons learned.
The incident response plan template exists for exactly this; version history and distribution records matter now.
Access Control for Transmission: control physical access to system transmission and distribution lines.
Mostly a walk-down item for facilities: where do cables and network drops run, and can an outsider reach them.
A facility note in the physical-protection statement; photos or walkdown records where relevant.
Risk Response: respond to findings from assessments, monitoring, and audits — accept, mitigate, transfer, or avoid, and record the decision.
Findings can no longer age silently: each needs a dispositioned decision with an owner. The risk register is the operating surface.
Risk register entries with treatment decisions and dates; POA&M linkage for mitigations.
Information Exchange: agreements governing CUI exchange between your system and others.
Every deliberate boundary crossing — prime portals, supplier exchanges — should trace to an agreement or documented understanding of protections.
The boundary-crossings table in the scoping worksheet seeds the exchange list; contracts and agreements are the evidence.
Information Management and Retention: manage and retain CUI within the system in accordance with applicable requirements.
Retention and disposal of CUI becomes a named obligation — decide how long contract data lives and how it leaves.
A retention schedule referenced from the data-handling policy.
Planning family additions: security policies and procedures, and rules of behavior, become explicit requirements (the SSP arrives from 3.12.4).
The governance paperwork Rev. 2 assumed is now named: policies covering the requirement families, and signed rules of behavior for CUI handling.
A policy framework index and a signed rules-of-behavior record per person.
Unsupported System Components: replace unsupported components, or document and mitigate when replacement is not possible.
The end-of-life problem gets requirement language: an EOL register with replace-or-mitigate decisions, which is precisely the technical-debt-reduction practice's territory.
The EOL/technical-debt register with dated decisions and compensating measures.
External System Services: require external service providers to meet your security requirements, and define oversight and user responsibilities.
MSPs, clouds, and hosted tools need stated security expectations and someone watching them — the shared-responsibility conversation, formalized.
Provider expectations in contracts or terms; the responsibility matrix; provider review records.
The Supply Chain Risk Management family: a SCRM plan, acquisition strategies and methods, and supply chain requirements and processes.
Supplier security stops being voluntary diligence: a plan, acquisition-time controls, and enforced requirements for the components and services your system depends on. For OT, component provenance and vendor maintenance access sit at the center.
A short SCRM plan, supplier questionnaires and risk assessments, and contract security requirements — the supply-chain artifacts in this library map here.
Two or more Rev. 2 requirements combined into one Rev. 3 requirement.
Four remote-access requirements — session monitoring and control, cryptographic confidentiality, managed access control points, and privileged remote authorization — become one Remote Access requirement.
Nothing you built for the four is wasted; it now has one home. Expect an assessor conversation to walk all four legacy behaviors under a single heading, so a gap in any one of them is now a gap in 03.01.12.
Merge four implementation statements into one narrative covering monitoring, encryption, brokering, and privileged authorization. The remote access pathway inventory becomes the single working artifact behind it.
Wireless authorization and wireless protection combine into one Wireless Access requirement.
Authorization-before-connection and authentication-plus-encryption are now assessed together; a guest network that was authorized but weakly protected no longer splits the difference.
One wireless statement covering both authorization records and protection configuration.
Mobile device connection control absorbs CUI encryption on mobile platforms.
Managing the device and encrypting what it carries are one conversation — practically, device management enrollment with enforced encryption.
Combine the mobile-device statement and the mobile-encryption statement; keep the enrollment and encryption policy exports as the evidence pair.
Use of external systems absorbs the portable-storage-on-external-systems limit.
External-system decisions (customer portals, home equipment, partner systems) and what removable storage may do there are evaluated as one policy.
One external-systems statement; the cloud and SaaS inventory carries the working list.
Security awareness and insider-threat awareness combine into Literacy Training and Awareness.
Insider-threat recognition stops being a separate once-a-year module and becomes part of baseline literacy — update the core deck rather than maintaining two.
Training records should show insider-threat content inside the literacy curriculum; the training matrix needs one row updated, not a new row.
Protecting audit information and restricting audit-management functions combine into Protection of Audit Information.
Same work, one heading: tamper protection and who-may-touch-logging are assessed together.
One statement covering log integrity protections and the short list of accounts that can manage logging.
Least functionality absorbs the nonessential programs/ports/protocols/services restriction.
One essential-capabilities review instead of two overlapping ones; the periodic review of what is enabled becomes explicit.
A single least-functionality statement with the review cadence written down.
Identifier reuse and inactivity disabling combine into Identifier Management.
One identifier lifecycle: issue, characterize, prevent reuse, disable on inactivity — the dormant-account sweep is now part of a named requirement.
One identifier-management statement; the access review worksheet and the automated sweep records evidence it.
Four password requirements consolidate into Password Management, aligned with current federal guidance — breached-password screening in, composition arithmetic out.
Modernize rather than translate: blocklists and length replace complexity rules and forced rotation. Directory settings likely change; appliance passwords still need the storage and transmission protections.
Replace four statements with one; update the password standard to the 800-63B-aligned posture and record the change as deliberate.
Maintenance tools control, off-site sanitization, and diagnostic-media checking consolidate around Maintenance Tools; personnel supervision splits to 03.07.06.
The maintenance conversation narrows to: what tools and media enter, what leaves sanitized, who is supervised. OT shops should map vendor service visits against exactly those three.
One tools-and-media statement plus the personnel statement; the vendor remote-access and visit records are the evidence.
Media transport accountability absorbs transport cryptography.
Transporting CUI on media means custody records and encryption together — one decision, not two requirements.
One transport statement; custody log plus encryption configuration as paired evidence.
Removable-media control absorbs the ownerless-device prohibition.
One media-use policy covering what is allowed, on what, and never anything without an identifiable owner.
Single media-use statement; endpoint policy export as evidence.
Visitor escort, physical access logs, and access-device management consolidate into Physical Access Control.
The front-desk trio becomes one requirement; small facilities can describe one coherent process instead of three fragments.
One physical-access statement covering visitors, logs, and keys/badges.
Vulnerability scanning and remediation combine into Vulnerability Monitoring and Scanning, with organization-defined frequencies and response times.
Your scan cadence and your fix-by times become declared parameters you are held to — decide them deliberately and make them achievable, including for OT assets where windows constrain timing.
Write the frequencies and response times down once, in the vulnerability management standard, and make the register show them operating.
User/management separation, public-access subnetworks, and split-tunneling prevention fold into Boundary Protection.
Boundary protection becomes the umbrella conversation: DMZ design, management-plane separation, and remote-client tunneling discipline are examined as aspects of one architecture.
One boundary statement backed by the segmentation plan; retire the three fragments.
Transmission confidentiality and CUI-at-rest confidentiality merge into Transmission and Storage Confidentiality.
Encryption in motion and at rest is one requirement now; a gap in either is a gap in the whole. FIPS-validated cryptography expectations (03.13.11) still ride alongside.
Combine the two statements; keep transport-security and storage-encryption configuration exports as the paired evidence.
Malicious-code protection, its update requirement, and periodic/real-time scanning consolidate into one requirement.
Modern endpoint protection platforms already do all three; the consolidation mostly removes redundant statements rather than work.
One malicious-code statement; the platform's policy export and detection reports evidence it.
Attack monitoring and unauthorized-use identification combine into System Monitoring.
Inbound/outbound attack detection and spotting unauthorized use are one monitoring capability with organization-defined objectives — for OT, passive network monitoring remains the realistic mechanism.
One monitoring statement; the coverage matrix and sampled alerts evidence it.
One Rev. 2 requirement distributed across multiple Rev. 3 requirements.
Baseline configurations and system inventories separate into Baseline Configuration and System Component Inventory.
Inventory stops hiding inside configuration management: it is now independently assessable, with its own update expectations. Organizations that kept a baseline document but a stale inventory lose the place to hide.
Two statements and two artifacts — the baseline worksheet and the asset inventory — each with its own owner and cadence.
Identification and authentication separate into a user requirement (with re-authentication made explicit) and a device requirement.
Device identification stops riding along: expect to answer how devices authenticate to the network and services, not just people. Re-authentication conditions become checkable.
Split the statement; device identity needs its own evidence (certificates, machine accounts, network access control).
Carried forward but with scope, specificity, or parameterization changes that affect implementation.
Rev. 2's broad logging expectations are restructured into explicit event-logging, record-content, and record-generation requirements with organization-defined event types and review cadences.
You now need a written answer to 'which event types do you log and when did you last revisit that list' — not just logs that exist. Record content (who, what, when, where, outcome) is separately checkable.
Write down the selected event types and the review cadence; the logging coverage matrix becomes the natural home.
Rev. 2 allowed deny-by-exception OR allow-by-exception software policy; Rev. 3's Authorized Software — Allow by Exception permits only the allowlist model, and absorbs user-installed software control.
If you relied on blocklisting, this is one of the genuinely new lifts in Rev. 3: build and maintain an authorized-software list and enforce execution against it.
The approved-software standard becomes a required artifact; user-install handling folds into it.
Substantively the same requirement under a new identifier.
The system security plan requirement moves to the new Planning family.
No change to what an SSP is or does; the assessor finds it under Planning now.
Update cross-references in your SSP and index documents from 3.12.4 to 03.15.02.
Secure engineering principles move to the new System and Services Acquisition family as Security Engineering Principles.
Same expectation — engineering discipline in how systems are built and changed — now framed at acquisition and engineering level.
Move the statement; development and architecture review records remain the evidence.
Present in Rev. 2 (or early Rev. 3 drafts); not carried as a standalone requirement in Rev. 3 — usually incorporated elsewhere.
'Perform maintenance' is not carried into Rev. 3 as a security requirement.
Keep doing maintenance; stop writing a security implementation statement for the concept of doing it. The controlled aspects live in tools, nonlocal sessions, and personnel.
Retire the 3.7.1 statement; nothing replaces it directly.
The VoIP-specific requirement is not carried forward as a standalone item.
Voice systems do not become exempt — they fall under boundary protection, transmission confidentiality, and monitoring like any other communication technology. Verify the disposition against NIST's official analysis of changes before removing anything.
Retire the VoIP-specific statement; ensure voice platforms appear in the systems the general statements cover.
