CNSSI 1253: Categorising and Selecting Controls for National Security Systems

Teams that know NIST SP 800-53 well often get national security systems wrong, because CNSSI 1253 changes how those systems are categorised, which controls they start with and which parameter values they must use. CNSSI No. 1253, Security Categorization and Control Selection for National Security Systems, is the Committee on National Security Systems (CNSS) instruction that sits on top of the NIST Risk Management Framework for national security systems (NSS). This guide explains who it applies to, how its categorisation and baselines differ from the civilian NIST approach, how overlays are layered on, what it demands of account and authenticator management, and how to build the evidence an authorising official expects. It is written for system owners, ISSOs and ISSMs, security engineers and defence or intelligence contractors who run NSS. For the general mechanics of overlays, see the NIST Control Overlays Guide; this page stays on what is specific to CNSSI 1253.

Key takeaways

• No high-water mark. The current CNSSI 1253 (29 July 2022) keeps three separate Low, Moderate or High values for confidentiality, integrity and availability instead of rolling them up the way FIPS 200 does for civilian systems.
• NSS baselines are NIST baselines plus. Appendix D marks NIST SP 800-53B selections with "X" and adds NSS controls marked "+", each with a justification such as Insider Threat, Advanced Persistent Threat or NSS Best Practice.
• Parameter values are fixed, not chosen. Many organisation-defined parameters in SP 800-53 are filled in by the instruction, for example quarterly account reviews, a 30 minute device lock and a 30 minute disable for high-risk users.
• Overlays carry the hard cases. Classified processing, cross-domain solutions, space platforms, intelligence systems and personally identifiable information are handled by overlays published as attachments to Appendix E.
• You cannot tailor out what you cannot afford. Controls may not be removed because of resource constraints; they stay applicable, with compensating controls and POA&M entries documented and approved by the authorising official.

What it is and who it applies to

CNSSI 1253 is issued by the CNSS under National Security Directive 42. The current edition is dated 29 July 2022 and supersedes the edition of 27 March 2014. It adopts NIST SP 800-37 Rev. 2 for the Categorize and Select steps of the Risk Management Framework, and NIST SP 800-53 Rev. 5 and SP 800-53B for the control catalogue and baselines. Section 1.1 states that it applies to all national security systems and that, where NIST publications differ, the instruction takes precedence. CNSS Policy No. 22, the CNSS cybersecurity risk management policy, is the policy that makes the NIST publications applicable to NSS in the first place.

Whether a system is an NSS is a legal question, not a preference. The definition in 44 U.S.C. 3552(b)(6) covers any information system used or operated by an agency, a contractor or another organisation on an agency's behalf whose function, operation or use:

• Intelligence: involves intelligence activities.
• Cryptology: involves cryptologic activities related to national security.
• Command and control: involves command and control of military forces.
• Weapons: involves equipment that is an integral part of a weapon or weapons system.
• Mission critical: is critical to the direct fulfilment of military or intelligence missions, excluding routine administrative and business applications such as payroll, finance, logistics and personnel management.
• Classified: is protected at all times by procedures established for classified information.

NIST SP 800-59 (August 2003) provides a checklist for making that determination. It sets no security requirements itself; it only helps agencies identify NSS consistently. Contractors meet CNSSI 1253 through their contracts and through the sponsoring agency's authorisation process: a contractor-operated classified network or a weapons system support environment is an NSS even when it sits on contractor premises.

Structure and key requirements

Categorisation without a high-water mark

Under CNSSI 1253, information owners assign impact levels to their information types using FIPS 199 and NIST SP 800-60 Rev. 1. The owner may sit outside the organisation that operates the system, which is common when a system processes another agency's intelligence. The result is a security category with three discrete values, written as a trigraph such as M-M-H or H-H-M. Section 1.2 states plainly that the FIPS 200 high-water mark is not adopted for NSS.

The practical effect is that a system needing high integrity and availability but only moderate confidentiality (a weapons system sensor feed, for example) does not inherit every High confidentiality control. Equally, a system holding highly sensitive data with a modest availability need is not forced into High availability controls such as alternate processing sites. Section 3.1.2 also forbids adjusting the categorisation to get a more or less stringent control set: that is what tailoring is for. The authorising official (or designee) approves the categorisation, and the senior agency official for privacy (SAOP) approves it for systems processing PII.

Appendix D baselines

Appendix D contains tables D-1 to D-20, one per SP 800-53 control family. Each table shows, per control:

• C, I and A associations: which security objective the control supports, so the baseline for any trigraph is assembled objective by objective.
• Selection symbols: "X" for a control selected in an SP 800-53B baseline, "+" for a control added for NSS, "--" for a control NIST selected that the NSS baseline does not.
• Justification: for "+" controls, the reason, such as Insider Threat (the instruction points to CNSSD No. 504), Advanced Persistent Threat or NSS Best Practice.
• Parameter values: the values NSS must use for organisation-defined parameters, labelled 1st PV, 2nd PV and so on.
• Tailoring columns: Assurance, Resiliency and ATT&CK, which flag controls that support those concerns.
• Privacy Implementation Considerations: a flag on controls whose implementation may create privacy risk, such as extensive monitoring.

Section 2.4 explains the extra controls. CNSSI 1253 accepts the SP 800-53B assumptions (multi-user systems, relatively persistent information) and adds NSS assumptions: insider threats exist and advanced persistent threats may already be present inside the system. It also notes what the baselines do not address: classified information processing, information needing specialised protection and cross-domain communication. Those come from overlays.

Overlays in Appendix E

Overlays are sets of controls and parameter values agreed by subject matter experts and published separately as attachments to Appendix E, so they can be updated without reissuing the instruction. The 2022 edition names the Classified NSS overlay, the Cross Domain Solutions (CDS) overlay, the Space Platform overlay, the Privacy overlays and the Intelligence overlays. Every NSS implements the NSS privacy baseline; systems that process PII also apply the relevant Privacy overlay, and the SAOP decides whether a system processes PII. Related community overlays exist too: the Insider Threat Overlays (dated September 2018) build on CNSSI 1253 baselines and apply where an organisation must run an insider threat programme under Executive Order 13587. Always confirm the current attachment versions on the CNSS website before you start, because they change independently of the main instruction.

Tailoring rules

Section 2.6 and 3.2.2 allow tailoring unless law, regulation or policy requires a control. The sequence is: apply overlays, resolve conflicts between overlays, apply scoping considerations, assign remaining organisation-defined parameters, supplement the baseline, then document every decision. Two rules surprise teams coming from civilian work. First, a control cannot be tailored out because the organisation cannot meet it, for example for lack of budget or tooling: it stays applicable and goes into the POA&M. Second, compensating controls are allowed but must be documented and accepted. The authorising official approves the security plan and the SAOP approves the privacy plan.

Identity and NHI requirements

The NSS insider threat assumption shows up most clearly in the access control and audit families. The values below come from Table D-1 and Table D-3 of the 2022 edition; confirm them against your current copy and any applicable overlay, which may tighten them further.

SP 800-53 already separates identity types: IA-2 covers organisational users, IA-3 devices, IA-4 identifier management, IA-5 authenticator management and IA-9 service identification and authentication. On an NSS these apply to every service account, API key, certificate and automation credential, not only to people. The instruction does not create a separate category for non-human identities, so the practical work is to make sure your account inventory, quarterly AC-2 review and AC-2(13) rapid disable process cover them. A high-risk individual who leaves behind a working deployment key has not been disabled in any meaningful sense. See the Service Account Security Guide and the Insider Threat and Identity Guide.

For AI agents and automated tooling on NSS, treat each agent as a service under IA-9 with its own identifier under IA-4, privileged only where AC-6 justifies it, and logged under the CNSSI 1015 event set. Agents that act on behalf of users should not reuse a human's credentials, because that defeats AC-2 attribution and the concurrent session limit.

Implementation steps

1. Confirm NSS status. Run the SP 800-59 checklist against 44 U.S.C. 3552(b)(6) with the sponsoring agency and record the outcome. Get written agreement on which authorising official owns the system.
2. Collect the current documents. Obtain CNSSI 1253 (2022), the applicable Appendix E attachments, CNSSI 1015 for audit events and any agency supplements. Record versions in the system security plan.
3. Categorise per objective. List information types with their owners, assign C, I and A values from FIPS 199 and SP 800-60, and write the trigraph. Get approval from the authorising official, plus the SAOP if PII is involved.
4. Assemble the baseline. For each Appendix D table, pick the controls associated with each objective at its level, including "+" additions and excluding "--" items. If you use GRC tooling to assemble the baseline, confirm which CNSSI 1253 edition it implements.
5. Apply overlays. Classified NSS, CDS, Space Platform, Privacy and Intelligence overlays as applicable, then any agency or programme overlays such as insider threat. Record each conflict and how it was resolved.
6. Set parameters and supplement. Use CNSSI 1253 values where given; set the rest by policy; add controls the risk assessment calls for.
7. Document tailoring. In the security plan (PL-2) record every scoping decision and compensating control; record controls you cannot yet meet in the POA&M (CA-5). Do not mark unmet controls "not applicable".
8. Implement and test in stages. Pilot account and audit controls on a non-production enclave, verify the 30 minute disable and 24 hour notification paths, then roll out. Keep the previous configuration baselines so a failed change can be rolled back.

Small contractor enclaves usually inherit most controls from the sponsoring agency or a common control provider and should focus on the system-specific controls and evidence. Large programmes benefit from a common control catalogue mapped to CNSSI 1253 so each system plan inherits rather than re-documents. See the NIST Risk Management Framework (SP 800-37) Guide and the NIST SP 800-53B Control Baselines and Tailoring Guide.

Evidence and assessment

Assessors check that the control set matches the categorisation and that each control works. Prepare these artefacts:

• Categorisation record: information types, owners, impact values per objective, trigraph and approval signatures.
• Control selection worksheet: Appendix D selections by objective, overlays applied, conflicts resolved and the CNSSI 1253 edition used.
• System security plan and privacy plan: implementation statements per control, inherited controls and their providers, parameter values.
• Tailoring and compensating control log: each decision with rationale and approver.
• POA&M: unmet controls with milestones; see the Plan of Action and Milestones (POA&M) Guide.
• Operational evidence: quarterly account review records covering service accounts, weekly audit review records, tests of the high-risk disable process with timestamps.

Measure that the controls keep working after authorisation:

• Account review coverage: percentage of accounts, human and non-human, reviewed in the last quarter (target 100%).
• Rapid disable time: median minutes from high-risk notification to all associated accounts and credentials disabled (target under 30).
• Change notification latency: share of joiner, mover and leaver events reaching account managers within 24 hours.
• Audit review cadence: weeks in the period with a completed review (target every week).
• POA&M age: number of items past their milestone date.

Feed these into continuous monitoring. See the NIST SP 800-137 Information Security Continuous Monitoring Guide.

Mapping to other frameworks

FedRAMP and DoD cloud authorisations also start from SP 800-53, but they use the high-water mark and their own parameter values, so an authorisation for one does not carry over to an NSS automatically. A cloud provider may attest to a CNSSI 1253 control selection (for example a High-High-High baseline) and the agency still decides on overlays and inherited controls. See the FedRAMP Guide and the NIST SP 800-53 Privacy Controls and FIPS 199/200 Categorisation Guide.

Common pitfalls

• Applying the high-water mark out of habit. Teams categorise M-M-H as "High" and implement every High control, spending effort on confidentiality controls the data does not need while possibly missing the objective-specific selections.
• Using an old edition. The 2014 edition was built on SP 800-53 Rev. 4. Control selections, parameter values and overlay references changed in 2022; check the edition in your tooling.
• Treating overlays as optional. A classified system without the Classified NSS overlay, or a PII system without the Privacy overlay, has an incomplete control set no matter how good the baseline implementation is.
• Tailoring out for cost. Marking a control "not applicable" because it is expensive breaks the section 2.6 rule and is a frequent assessment finding. Use compensating controls and the POA&M.
• Human-only account reviews. Quarterly AC-2 reviews that list people but skip service accounts, certificates and API keys leave the most persistent credentials unreviewed.
• Untested rapid disable. A 30 minute AC-2(13) target means nothing without a rehearsed runbook that reaches every directory, PKI and secrets store.

Practitioner checklist

• Record the NSS determination against 44 U.S.C. 3552(b)(6) and the SP 800-59 checklist.
• Confirm you are using CNSSI 1253 (29 July 2022) and the current Appendix E attachments.
• Categorise each objective separately and get AO (and SAOP where PII) approval of the trigraph.
• Build the baseline from Appendix D including "+" additions, and apply every applicable overlay.
• Adopt CNSSI 1253 parameter values, such as quarterly account review and the 30 minute device lock.
• Include service accounts, keys, certificates and AI agents in AC-2 inventories and reviews.
• Test the AC-2(13) 30 minute disable path end to end, including non-human credentials.
• Configure auditing for the CNSSI 1015 event set and review at least weekly.
• Document tailoring and compensating controls; put unmet controls in the POA&M, never "not applicable".
• Track coverage, disable time and POA&M age as continuous monitoring metrics.

Standards and references

• CNSS: CNSSI No. 1253, Security Categorization and Control Selection for National Security Systems (2022 edition, copy)
• US Code: 44 U.S.C. 3552, Definitions (national security system)
• NIST: SP 800-59, Guideline for Identifying an Information System as a National Security System
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• ODNI National Counterintelligence and Security Center (archive): Insider Threat Overlays
• NIST: Security and Privacy Control Overlay Repository

Related NHI Mgmt Group resources: NIST Control Overlays Guide · NIST SP 800-53 Guide · Insider Threat Programme Guide · Defence Industrial Base Identity Security Guide