NIST SP 800-53 and SP 800-171 for Linux servers: control families and what they mean on a real machine
Publisher: NIST (US National Institute of Standards and Technology) 800-53 is used by US federal agencies (FISMA) and FedRAMP 800-171 protects Controlled Unclassified Information (CUI) in non-federal systems, for example defence contractors
NIST publishes catalogues of security controls. They say WHAT outcome you need ("enforce a limit of consecutive invalid logon attempts") and leave the HOW to you or to a baseline built on top of them. This sheet explains the two documents most Linux admins meet and maps the controls that touch servers to Linux settings. It is a guide, not legal or assessor advice: the agency, contract or assessor decides which baseline applies.
Facts checked 2026-09-29.
NIST SP 800-53 (Security and Privacy Controls for Information Systems and Organizations)
- Current release: Release 5.2.0, published August 27, 2025. It is a revision-5 document with 20 control families and over a thousand controls and control enhancements (about 1,196 as counted by one source).
- Rev 5 added two families: PT (PII processing and transparency) and SR (supply chain risk management).
- You do not implement everything. You select a baseline (Low, Moderate or High impact, defined in SP 800-53B) and tailor it. FedRAMP baselines are built on these.
- NIST's Cybersecurity and Privacy Reference Tool (CPRT) lets you browse and export the controls: https://csrc.nist.gov/Projects/risk-management/sp800-53-controls/release-search
NIST SP 800-171 (Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations)
- Revision 2: 110 security requirements in 14 families (for example 3.1 Access Control, 3.3 Audit and Accountability, 3.5 Identification and Authentication, 3.13 System and Communications Protection, 3.14 System and Information Integrity).
- Revision 3: published May 14, 2024. It reorganises the requirements into 17 families and reduces the count to 97, and adds organisation-defined parameters that the agency owning the CUI can set.
- Which revision applies depends on your contract. The US Department of Defense issued a class deviation in May 2024 telling contractors to keep using Revision 2 for DFARS 252.204-7012 until the deviation is rescinded. Check your contract and current DoD or CMMC rules.
The families that touch a Linux server (800-53 IDs, with the matching 800-171 Rev 2 family)
800-53 Linux example 800-171 Rev 2
AC-2 Account management Unique accounts, groups by role, disable leavers, periodic review 3.1.1, 3.1.2
AC-3 Access enforcement File permissions, sudoers, SELinux/AppArmor 3.1.1, 3.1.2
AC-6 Least privilege No shared root, limited sudo, service accounts with no shell 3.1.5, 3.1.6
AC-7 Unsuccessful logon attempts pam_faillock (for example deny = 3-5, timed unlock) 3.1.8
AC-8 System use notification (banner) /etc/issue.net and the SSH Banner setting 3.1.9
AC-11 Device lock / AC-12 Session termination TMOUT, SSH ClientAlive settings, screen lock 3.1.10, 3.1.11
AC-17 Remote access SSH hardening, VPN, MFA, encrypted sessions 3.1.12 to 3.1.15
AU-2 / AU-3 Event logging and its content auditd rules, journald, application logs (who, what, when, where) 3.3.1, 3.3.2
AU-6 Audit review and analysis Central logging, alerts, regular review 3.3.5
AU-8 Time stamps chrony / NTP to a trusted source 3.3.7
AU-9 Protection of audit information Restricted log permissions, remote log server, append-only options 3.3.8, 3.3.9
AU-11 Audit record retention Retention policy on the log server (no direct Rev 2 equivalent)
CM-2 / CM-6 Baseline and configuration settings A CIS or STIG baseline, tracked in config management 3.4.1, 3.4.2
CM-7 Least functionality Remove or disable unneeded services, ports and packages 3.4.6, 3.4.7
CM-8 System component inventory A current asset and software inventory 3.4.1
IA-2 Identification and authentication (MFA) MFA for privileged and remote access 3.5.1 to 3.5.3
IA-5 Authenticator management Password quality (pwquality), key management, no default credentials 3.5.7 to 3.5.10
RA-5 Vulnerability monitoring and scanning Scheduled vulnerability scans and OVAL/OpenSCAP scans 3.11.2
SC-7 Boundary protection Host firewall, network segmentation 3.13.1, 3.13.5, 3.13.6
SC-8 Transmission confidentiality TLS, SSH, IPsec/WireGuard 3.13.8
SC-12 / SC-13 Cryptographic key management and use FIPS-validated crypto where required (RHEL FIPS mode), key rotation 3.13.10, 3.13.11
SC-28 Protection of information at rest LUKS disk encryption, encrypted backups 3.13.16
SI-2 Flaw remediation Patching within your defined timelines, plus reboot process 3.14.1
SI-3 Malicious code protection Endpoint agent or ClamAV where appropriate 3.14.2
SI-4 System monitoring Logging, IDS, alerting 3.14.6, 3.14.7
SI-7 Software, firmware and information integrity AIDE or other file integrity monitoring, signed packages (no direct Rev 2 equivalent)
CP-9 System backup Encrypted, tested, off-machine backups (no direct Rev 2 equivalent)
The 800-171 numbers are Revision 2 requirement IDs and are given as a starting map: check them against the document you are assessed against, because Revision 3 renumbered and reorganised the requirements.
Tools on Linux
Red Hat family: scap-security-guide includes a cui profile (mapped to NIST SP 800-171 for controlled unclassified information) and an ospp profile (the operating-system protection profile used in Common Criteria evaluations), alongside stig, cis, pci-dss and hipaa.
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml # list all profiles for your release
oscap info --profile cui /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
sudo oscap xccdf eval --profile cui --results cui-results.xml --report cui-report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
# Red Hat provides no automated undo for remediation: generate the fix script, review it, test on a copy, snapshot first
Ubuntu: use the STIG (usg audit disa_stig) or a CIS profile (usg audit cis_level1_server) as your documented baseline, and map the results to the controls you need. Both need Ubuntu Pro. See the OpenSCAP, USG and Lynis sheet.
Whichever tool you use, check which NIST revision or baseline it maps to (oscap info shows the profile description). Profile mappings can lag the newest NIST release.
For FedRAMP or federal work you also need the documents around the controls: a system security plan (SSP), a plan of action and milestones (POA&M) and a continuous monitoring process. The Linux settings are only one part.
A workable process
1. Find out exactly which document and baseline apply to you (800-53 Moderate, 800-171 Rev 2, or Rev 3) and write it down.
2. Decide the boundary: which systems handle the protected data. Keep it small and segmented.
3. Map each control to a specific setting, tool or procedure (a table like the one above, extended for your systems).
4. Implement on a baseline (CIS or STIG) and scan it.
5. Collect evidence: scan reports, config exports (sshd -T, audit rules, account lists), logs, patch records, review records.
6. Track gaps in a POA&M with an owner and a date.
7. Monitor continuously: scheduled scans, patching and log review.
Common problems
"Which controls do I actually need?": the baseline (Low/Moderate/High) or your contract decides. Do not try to implement all of 800-53.
"We follow 800-171 Rev 3 but our contract says Rev 2": follow the contract. Ask your contracting officer, and keep the mapping for both if you can.
"Our scanner says 100% but the assessor found gaps": scanners check system settings. Assessors also examine policies, training, boundaries, documentation and how you operate.
"The requirement says 'organisation-defined': what do I pick?": you (or the agency, for 800-171 Rev 3) set values such as lockout thresholds and log retention. Write them into policy and implement exactly that.
"FIPS": some requirements want FIPS-validated cryptography. That means using a validated module and enabling FIPS mode where the OS supports it, not only using strong algorithms. Plan it early.
"Cloud provider is FedRAMP authorised, so we are fine": their authorisation covers their part. Your workload, configuration and access are still yours.
Tips
Do the mapping once, in a spreadsheet or a small YAML file, and reuse it for every framework: most controls overlap with CIS, PCI DSS, HIPAA and ISO 27001 (see those sheets).
Keep evidence generation automated (a scheduled job that saves scan reports and config exports with a date).
Use CIS or STIG as the technical baseline: they save you from inventing your own.
Every "organisation-defined" value needs an owner and a review date.
"Controlled Unclassified Information" is the official name for "sensitive but not secret". The paperwork is not unclassified in spirit.
Sources (checked 2026-09-29)
NIST SP 800-53 Release 5.2.0 summary of changes (Aug 27, 2025): https://csrc.nist.gov/csrc/media/Projects/risk-management/800-53%20Comment%20Site/SP800-53-r5.2.0-changes.pdf
NIST Cybersecurity and Privacy Reference Tool (controls): https://csrc.nist.gov/Projects/risk-management/sp800-53-controls/release-search
NIST SP 800-171 Revision 3 (final, May 14, 2024): https://www.crowell.com/en/insights/client-alerts/nist-releases-final-version-of-nist-sp-800-171-revision-3
DoD class deviation keeping Revision 2 for DFARS 7012: https://www.crowell.com/en/insights/client-alerts/miss-me-with-rev-3-says-dod-dod-issues-class-deviation-linking-dfars-7012-to-nist-sp-800-171-rev-2
Red Hat, compliance scanning (profiles cui, ospp, stig ...): https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/scanning-the-system-for-configuration-compliance-and-vulnerabilities_security-hardening