A defense contractor's ATO renewal is due in six weeks. The system owner has a stack of NIST SP 800-53 controls to re-assess, a Plan of Action and Milestones (POA&M) with 40 open items, and a security team that's never actually mapped its software supply chain into the authorization package. This is what NIST 800-37 looks like in practice — not an abstract compliance framework, but a recurring, deadline-driven process that determines whether a system is allowed to operate on federal networks at all.
NIST Special Publication 800-37 Revision 2, published in December 2018, is the government's standard playbook for managing security and privacy risk across the life of an information system. It's mandatory for federal agencies under FISMA and the basis for FedRAMP, DoD RMF, and much of the vendor risk language showing up in commercial contracts. If you sell software to the federal government — or to anyone who does — you'll eventually run into it. Here's what it actually requires, and where most teams get stuck.
What Is the NIST 800-37 Risk Management Framework?
NIST 800-37 is a seven-step process for categorizing, securing, and continuously monitoring federal information systems so an authorizing official can make an informed decision about whether the system's risk is acceptable. It replaced the older Certification and Accreditation (C&A) model in 2010 (Revision 1) and was updated in 2018 (Revision 2) to integrate privacy risk management and align with the NIST Cybersecurity Framework. The end product of the RMF is an Authorization to Operate (ATO) — a formal, time-bound approval, typically valid for three years, though Revision 2 pushes agencies toward "ongoing authorization" based on continuous monitoring data rather than a fixed renewal date.
The framework doesn't specify which controls to implement — that's SP 800-53's job, with over 1,000 controls across 20 families in Revision 5. Instead, 800-37 tells you the process: categorize the system, pick controls, implement them, verify them, get authorized, and keep watching. It's process governance layered on top of a technical control catalog.
What Are the Seven Steps of the RMF?
The seven steps are Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor — and skipping the first one is the most common reason RMF packages stall. Prepare, added formally in Revision 2, requires organizations to define roles, risk tolerance, and a control baseline strategy before touching a single system. Categorize uses FIPS 199 to rate the system's confidentiality, integrity, and availability impact as low, moderate, or high — a moderate-impact system (the most common federal baseline) inherits roughly 261 controls from the SP 800-53 moderate baseline before tailoring.
Select narrows that baseline to what actually applies; Implement deploys the controls and documents them in a System Security Plan (SSP); Assess has an independent assessor test control effectiveness and produce a Security Assessment Report (SAR); Authorize is the point where an Authorizing Official reviews the risk and signs the ATO, accepts the risk, or denies it; and Monitor is the ongoing step — continuous monitoring, configuration management, and periodic reassessment for as long as the system operates. In practice, Assess and Monitor consume the most engineering time, because they require continuous evidence, not a one-time checklist.
Who Actually Has to Follow NIST 800-37?
Every federal agency information system is legally required to follow RMF under the Federal Information Security Modernization Act (FISMA), and that requirement flows downstream to contractors, cloud providers, and software vendors who touch federal data. FedRAMP, which governs cloud services sold to federal agencies, is built directly on 800-37 — a FedRAMP Moderate authorization is essentially an RMF package with FedRAMP-specific overlays and a Joint Authorization Board or agency sponsor in the Authorize role. The DoD's RMF (DoDI 8510.01) is the same seven-step process with DoD-specific control overlays and the addition of a Risk Management Framework for DoD Information Technology.
For software vendors specifically, the pressure point is usually the SSDF — NIST SP 800-218 — which OMB Memorandum M-22-18 requires federal software suppliers to attest to. SSDF isn't the same document as 800-37, but assessors increasingly expect vendors to show how their secure development practices, SBOMs, and vulnerability management feed into a customer's RMF Categorize and Assess steps. A vendor that can't produce an SBOM or attest to build provenance becomes the reason an agency's ATO gets delayed.
How Does RMF Relate to SBOMs and Software Supply Chain Risk?
RMF's Categorize and Select steps increasingly require software composition evidence, because SP 800-53 Revision 5 added supply chain risk management (SR family) controls that didn't exist in earlier baselines — SR-1 through SR-12 cover everything from supplier risk assessments to component authenticity and counterfeit prevention. An assessor evaluating SR-4 ("Provenance") or SA-22 ("Unsupported System Components") will ask for an SBOM, not just a narrative description of the system's architecture.
This is exactly the seam where a lot of compliance tooling in this space, including Anchore's, has focused — SBOM generation and container image scanning aimed at satisfying the Executive Order 14028 and SSDF requirements that feed into RMF evidence. That's necessary but incomplete: an SBOM alone answers "what's in the build," not "is the ATO package's evidence still accurate six months after Authorize." Continuous monitoring under RMF's seventh step requires that component inventories, vulnerability status, and control effectiveness stay current between reassessments — not just at initial submission. A tool that produces a point-in-time SBOM but doesn't track drift against the SSP over the authorization period leaves exactly the gap where POA&M items pile up.
Where Do Most Teams Get Stuck Implementing RMF?
Most teams get stuck at Assess and Monitor, not at Categorize or Select, because those first steps produce a document while the last two require sustained, verifiable evidence. A 2023 GAO review of federal agency FISMA compliance found recurring findings around incomplete continuous monitoring and stale POA&Ms — the same failure mode shows up in FedRAMP annual assessments, where lapsed vulnerability remediation timelines (30 days for critical, 90 for high, under FedRAMP's SLA) are among the most common reasons for a corrective action plan.
The underlying problem is usually tooling fragmentation: SBOM data lives in one system, vulnerability scan results in another, control narratives in a spreadsheet or GRC tool that nobody updates in real time. When an assessor asks for evidence that SR-4 or SI-2 (flaw remediation) has been continuously satisfied, teams end up manually reconciling three or four sources instead of pulling from one. That reconciliation gap is where ATO renewals slip past their deadline and where three-year reauthorization cycles turn into scrambles.
How Safeguard Helps
Safeguard is built around the part of RMF that most tooling treats as an afterthought: keeping Categorize, Assess, and Monitor evidence continuously accurate instead of accurate only at submission time. Safeguard generates and continuously updates SBOMs across your build pipeline, maps discovered components and vulnerabilities directly to the SP 800-53 SR and SI control families assessors actually check, and keeps that mapping current as dependencies change — so the evidence behind your SSP and SAR doesn't go stale the day after Authorize.
Where point tools like Anchore stop at producing an SBOM or scanning a container image, Safeguard ties that data to the ongoing authorization lifecycle: tracking remediation against FedRAMP-style SLA windows, flagging when a new CVE affects a component already cited in your authorization package, and giving compliance teams a single source of truth instead of a monthly export-and-reconcile exercise. For teams managing DoD RMF, FedRAMP, or SSDF attestation obligations, that means less time assembling evidence manually before an assessment and fewer surprises during continuous monitoring.
If your organization is heading into a Categorize step for a new system, a reassessment ahead of an ATO renewal, or an SSDF attestation deadline, the fastest way to reduce risk isn't more documentation — it's supply chain visibility that stays current automatically. That's the gap Safeguard is built to close.