Skip to main content
  1. Index/

NIST 800-53

Table of Contents

NIST Special Publication 800-53 is published by the National Institute of Standards and Technology (NIST), a US federal agency within the Department of Commerce. The current version is Revision 5 (September 2020, updated December 2020), which defines over 1,000 security and privacy controls organized in 20 control families (Access Control, Audit and Accountability, Configuration Management, Incident Response, System and Communications Protection, Supply Chain Risk Management, etc.). NIST 800-53 is mandatory for US federal agencies and their contractors under FISMA (Federal Information Security Modernization Act) and serves as the control baseline for FedRAMP (cloud), CMMC (defense contractors), and many state/local government programs. Beyond the US, it is widely adopted internationally as a comprehensive reference catalog — organizations in finance, healthcare, and critical infrastructure worldwide use NIST 800-53 as their control framework. The standard defines three baselines (Low, Moderate, High) corresponding to the potential impact of a security breach. NIST 800-53 is not a certification itself but the control catalog against which systems are assessed; formal authorization (ATO — Authority to Operate) is granted by an authorizing official after an assessor verifies control implementation using NIST SP 800-53A assessment procedures. The companion OSCAL (Open Security Controls Assessment Language) standard, also from NIST, provides machine-readable formats for expressing 800-53 controls and assessment results.

Red Hat has extensive, documented alignment with NIST 800-53. RHEL and OpenShift provide technical implementations for hundreds of 800-53 controls across all 20 families. The most direct integration is through the OpenSCAP tooling shipped with RHEL, which includes SCAP content mapping RHEL configurations to NIST 800-53 control requirements — enabling automated assessment of an entire system against the Low, Moderate, or High baseline. The OpenShift Compliance Operator extends this to Kubernetes environments, scanning both the platform and the underlying RHCOS nodes against 800-53 derived profiles. Red Hat’s alignment goes beyond scanning: FIPS 140-3 validated cryptography satisfies SC (System and Communications Protection) family controls; SELinux and namespace isolation address AC (Access Control) requirements; auditd and OpenShift API audit logging implement AU (Audit and Accountability) controls; the Trusted Software Supply Chain directly addresses the SA-8 through SA-15 controls in the Supply Chain Risk Management family (new in Rev 5). Red Hat also invests in OSCAL: the complyctl tool and forthcoming Kubernetes-native compliance toolkit generate OSCAL-formatted assessment results, enabling machine-to-machine evidence exchange with GRC platforms — critical for the continuous monitoring that NIST 800-53 and FedRAMP demand. For federal customers, Red Hat’s FedRAMP High-authorized ROSA service directly inherits the NIST 800-53 Rev 5 High baseline, reducing customer assessment scope by up to 70 % of controls.

Additional Information
#

Related

FedRAMP

The Federal Risk and Authorization Management Program (FedRAMP) is a US government-wide program, codified into law by the FedRAMP Authorization Act of 2022, that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services used by federal agencies. FedRAMP is administered by the General Services Administration (GSA) and is mandatory — any cloud service (SaaS, PaaS, IaaS) that stores, processes, or transmits federal data or metadata must achieve FedRAMP authorization before it can be used by US government agencies or their contractors. The program defines three impact levels: Low (limited adverse effect), Moderate (serious adverse effect), and High (severe or catastrophic effect — applies to law enforcement, emergency, financial, and health systems). Each level maps to NIST SP 800-53 Rev 5 control baselines: FedRAMP High requires implementation of approximately 421 controls. Authorization is achieved through either an Agency ATO (a specific agency sponsors the assessment) or the newer FedRAMP 20-X experimental accelerated path. Once authorized, cloud service providers (CSPs) must maintain continuous monitoring — monthly vulnerability scans, annual penetration testing, and Plan of Action & Milestones (POA&M) reporting — or risk revocation. Authorized services are listed on the FedRAMP Marketplace.

FIPS 140-2 / FIPS 140-3

FIPS 140 (Federal Information Processing Standard, Publication 140) is the US and Canadian government standard that defines security requirements for cryptographic modules — the hardware, software, or firmware components that perform cryptographic operations (encryption, decryption, hashing, signing, key management). It is published by NIST (National Institute of Standards and Technology) and jointly administered with CCCS (Canadian Centre for Cyber Security) through the Cryptographic Module Validation Program (CMVP). The standard has two active versions: FIPS 140-2 (published 2001, no longer accepting new submissions since April 2022) and FIPS 140-3 (effective September 2020, the current standard for all new validations). FIPS 140-2 certificates remain valid until 21 September 2026, after which they move to the Historical list — meaning only FIPS 140-3 validated modules will be accepted for new federal procurements. FIPS 140 defines four security levels (Level 1 through Level 4), with Level 1 being the baseline for software modules and Level 4 requiring physical tamper-active hardware. Compliance is mandatory for all US federal agencies and their contractors under FISMA, for Canadian federal systems, and is widely adopted by regulated industries (finance, healthcare, critical infrastructure) globally. Non-validated cryptography is treated as providing no protection — effectively plaintext — regardless of the algorithm strength. Validation is a formal, lab-based process: vendors submit modules to accredited Cryptographic and Security Testing (CST) laboratories, which test against the standard and submit results to CMVP for certificate issuance.

HIPAA

The Health Insurance Portability and Accountability Act (HIPAA) is a United States federal law enacted in 1996 and enforced by the Department of Health and Human Services (HHS) Office for Civil Rights (OCR). HIPAA is not a voluntary standard or certification — it is mandatory US law with civil and criminal penalties for non-compliance (fines up to $1.5M per violation category per year, and criminal penalties including imprisonment). HIPAA applies to covered entities (health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically) and their business associates (any entity that creates, receives, maintains, or transmits Protected Health Information — PHI — on behalf of a covered entity). The law’s security requirements are defined primarily in two rules: the Privacy Rule (what PHI can be used and disclosed) and the Security Rule (administrative, physical, and technical safeguards required to protect electronic PHI — ePHI). Key technical requirements include access controls, audit controls, integrity controls, transmission security (encryption), and contingency planning. Unlike prescriptive standards (like CIS or DISA STIG), HIPAA’s Security Rule is flexible and scalable — it defines required outcomes but allows organizations to determine the specific technologies used. The Breach Notification Rule requires reporting unauthorized disclosures to HHS and affected individuals within 60 days. HIPAA has no “certification” — compliance is demonstrated through documented risk assessments, policies, and technical controls.