The Big Picture: The Army rebuilt RMF around three moves — threat-informed control selection, inheritance by default, and continuous monitoring. The DoD then replaced RMF department-wide with the CSRMC. If you work Army systems, you now operate under both.
Why It Matters
Legacy RMF produced 18-month authorizations and paperwork nobody read. RMF 2.0 cut the Army’s control baseline roughly 40% and pointed authorization at live monitoring instead of periodic reassessment. The CSRMC makes that direction DoD policy. Program teams that still run checklist-first RMF are executing a retired process.
The Details
- Threat-informed selection (Project Sentinel): Controls are prioritized against validated threats, not applied as a flat catalog. Result: Control Correlation Identifiers cut from 1,335 to 805 on SIPRNet and 1,208 to 769 on NIPRNet — about 40% less manual work per system.
- Inheritance by default: Systems inherit controls from the infrastructure and enterprise policies they ride on, through common control providers. One assessment covers many tenants.
- CSRMC (Sep 2025): The DoD CIO’s replacement for RMF — five phases aligned to the system lifecycle (Design, Build, Test, Onboard, Operations) and ten strategic tenets, with continuous monitoring and continuous ATO at the center.
Go Deeper
What Broke in RMF 1.0
The original RMF — NIST SP 800-37 as the DoD implemented it — treated every system as an island. Each program selected from the full NIST SP 800-53 catalog, documented every control in its own SSP, and re-proved at reassessment what the enterprise had already proven elsewhere. Three predictable failures:
- Flat baselines. Every control weighted the same, whether or not any adversary used it. Effort went where the catalog pointed, not where the threat was.
- Duplicated evidence. A hundred systems on the same network each documented the same infrastructure controls. Same proof, written a hundred times.
- Point-in-time authorization. The ATO described the system on assessment day. Every patch after that made the paperwork less true.
The Army hit these walls early and at scale — thousands of systems, one network, no way to staff the paperwork. RMF 2.0 was the response.
The Army’s Fix: Project Sentinel
Project Sentinel is the first phase of Army RMF 2.0. The mission: adapt the Unified Network Plan’s RMF process into a threat-informed risk decision process with far less overhead. Three mechanisms carry it.
1. Threat-informed control selection. Sentinel maps validated threats — from authoritative sources like the CIS Critical Security Controls — against the RMF catalog, and prioritizes the controls that counter real, current adversary behavior. This is what NIST always said to do (tailor the baseline); the Army built the process to actually do it. The measurable result: CCIs cut from 1,335 to 805 on SIPRNet and from 1,208 to 769 on NIPRNet — an average 40% reduction in manual control manipulation per system.
2. Inheritance and common control providers. The second mechanism is the same one that makes Continuous ATO scale: assess the shared infrastructure once, let every tenant system inherit. Common control providers document the enterprise controls — network defense, identity, physical security — and individual systems document only their delta. For a formation fielding hundreds of systems on one network, this is where the return on investment lives.
3. Continuous monitoring as the end state. The stated culmination of RMF 2.0 is continuous monitoring of technical controls, moving the Army from periodic reauthorization toward a continuous authorization model. The sentinel metaphor is the design intent: the watch never ends, so the authorization doesn’t expire on a calendar.
One honest caveat: reducing controls draws criticism. The counterargument from the assessor community is that a threat-informed cut risks trimming controls that matter against threats not yet on the validated list. The Army’s bet is that 805 controls actually monitored beat 1,335 controls documented and forgotten. I think that bet is right — but it only pays if the monitoring is real.
Then the DoD Replaced RMF Entirely
On 24 September 2025, the DoD CIO issued the Cybersecurity Risk Management Construct (CSRMC) — the department-wide replacement for RMF. The stated reason matches the Army’s diagnosis: static checklists and manual processes that ignored operational needs and cyber survivability.
CSRMC restructures risk management into five phases aligned to the system lifecycle:
| Phase | When | What happens |
|---|---|---|
| Design | Planning | Security as a design requirement; inheritance and enterprise services planned in, not bolted on |
| Build | Toward IOC | Controls implemented alongside functionality — DevSecOps checkpoints, not end-of-build review |
| Test | Before FOC | Threat-informed validation under operational conditions, not documentation review |
| Onboard | Fielding | System connects to the DoDIN with monitoring and dashboards active from day one |
| Operations | Sustainment | Real-time risk posture; authority to restrict or disconnect if risk exceeds tolerance |
Under the phases sit ten strategic tenets: automation, critical controls, continuous monitoring and ATO, DevSecOps, cyber survivability, training, enterprise services and inheritance, operationalization, reciprocity, and cybersecurity assessments. Read the list against Project Sentinel and the overlap is obvious — threat-prioritized critical controls, inheritance, continuous monitoring. The Army’s RMF 2.0 was, in effect, the pilot for what became DoD policy.
Two tenets deserve attention because they change behavior between organizations, not just within them:
- Reciprocity. An assessment done once gets reused across systems and components. The chronic failure mode of legacy RMF — every AO re-assessing what another AO already accepted — is now explicitly against the design.
- Cyber survivability. The system must keep operating in a contested environment, which shifts testing from “are the controls documented” to “does the system fight through degradation.” That’s the same requirement I covered from the JADC2 side in the software-defined battlefield post.
How the Two Frameworks Fit Together
If you’re on an Army program, the practical stack looks like this:
- CSRMC sets the structure — five lifecycle phases, ten tenets, DoD-wide.
- Army RMF 2.0 / Sentinel supplies the Army’s implementation — the threat-informed baseline, the common control providers, the monitoring infrastructure.
- NIST SP 800-53 still supplies the control language. CSRMC reorganizes how controls are selected, assessed, and monitored; it does not invent a new catalog. Your evidence still maps to 800-53 controls — there are just fewer of them, chosen for a reason.
The through-line from both frameworks is the same one running through this whole series: evidence must be produced by the system, continuously, not written about the system, annually. The cATO evidence pipeline is how you build that. CSRMC is the policy language that now requires it.
Where Programs Will Get This Wrong
1. Treating CSRMC as RMF with new labels. The five phases are not the six RMF steps renamed. The unit of work changed: from documents produced at gates to monitoring wired in from design. A program that maps its old SSP process onto the new phase names has missed the point and will fail the Operations phase.
2. Claiming inheritance without a provider. Inheritance requires a common control provider that actually documents and maintains the shared controls. “We’re on the enterprise network” is not inheritance — it’s an undocumented dependency. Name the provider, get the inheritance agreement in writing.
3. Building dashboards instead of monitoring. The Operations phase requires real-time risk posture that an authority can act on — including disconnection. A dashboard nobody watches, wired to thresholds nobody set, is dashboard theater. If a control fails at 0300 and no alert fires, you are not continuously monitoring; you are continuously displaying.
4. Ignoring reciprocity in both directions. Teams remember to claim other organizations’ assessments and forget to package their own for reuse. Under CSRMC, an assessment that another program can’t consume is half-finished work.
The Bottom Line
RMF 2.0 and CSRMC are the same judgment issued at two echelons: control catalogs don’t defend networks, and paperwork isn’t evidence. The Army proved the mechanics — threat-informed baselines, inheritance, continuous monitoring — and the DoD wrote them into the replacement framework.
If you own a system under this stack, three moves, in order: map your current controls to the threat-informed baseline and cut what falls outside it; get your inheritance agreements documented with a named common control provider; and wire monitoring into the pipeline before the Operations phase demands it. Do them now, while the transition gives you room — the programs that wait will be re-learning legacy RMF’s lesson on the new framework’s timeline.