- CPA to Cybersecurity
- Posts
- CSRMC vs NIST RMF with Jason Dion: What Changes (and What Doesn't) for Federal Cyber
CSRMC vs NIST RMF with Jason Dion: What Changes (and What Doesn't) for Federal Cyber
The Department of Defense (recently rebranded as the Department of War) announced it's replacing the Risk Management Framework with something called CSRMC - the Cybersecurity Risk Management Construct. To understand what this actually means, I spoke with Jason Dion, who spent years implementing Risk Management Framework (RMF) as a Navy cybersecurity officer and later at U.S. Cyber Command and NSA.
The conversation revealed something important: this isn't really a replacement. It's an evolution that acknowledges what practitioners have known for years - the way we've been doing security authorization doesn't match how modern systems actually work.
The Core Problem RMF Couldn't Solve
RMF was built for a world where systems were stable. You'd get your Authority to Operate (ATO), good for three years, and that was that. But as Dion points out, this created an obvious problem:
I can get inspected today and then three weeks from now have a hack because there's a new vulnerability that got released two weeks from now. And you wouldn't know that for another year.
The numbers tell the story. Getting an ATO typically took 12 to 24 months. Dion recalls designing a network for a joint exercise that needed nine months for certification. The approval came through nine months after the exercise ended, when the ship was already being decommissioned.
This wasn't just bureaucratic delay. It was a fundamental mismatch between the pace of technology change and the speed of security approval. By the time you documented a system thoroughly enough for approval, the system had already changed.
So What’s Different under CSRMC?
On paper, the new framework compresses RMF's seven steps into five phases, but that's mostly reorganization. The real changes are operational:
Continuous Everything: Instead of point-in-time certification, CSRMC emphasizes continuous monitoring, continuous assessment, and continuous authorization. This isn't new conceptually - NIST has pushed continuous monitoring since 2011. But the implementation is finally catching up to the concept.

Operational Control: Under RMF, certification authorities who approved systems often had no operational responsibility for defending them. Dion experienced this firsthand:
I'm responsible for defending Steve's network. But Joe over there is one who says Steve can connect the network. I never got to look at it.
CSRMC puts the Cybersecurity Service Providers (CSSPs) - the people who actually defend the networks - into the approval process. They validate controls before systems connect, not after.
Enterprise Focus: The framework elevates cyber from system-level compliance to enterprise risk management. Instead of treating each system as an isolated certification exercise, CSRMC views cybersecurity as an organizational risk alongside financial and legal concerns.
What Stays the Same
Despite the rebranding, much of RMF's foundation remains. The security objectives - confidentiality, integrity, and availability - don't change. The NIST control baselines (800-53) still apply. The FIPS 199 categorization of systems as low, moderate, or high impact continues.
As Dion notes, it's like the difference between the OSI model's seven layers and TCP/IP's four layers - you can map between them, but they're organized differently.

The same security work needs doing; CSRMC just acknowledges it needs doing continuously rather than every three years.
The documentation burden likely remains substantial. While CSRMC promises automation and continuous monitoring, someone still needs to configure those systems, interpret their outputs, and make risk decisions. The paperwork might be generated automatically, but it still exists.
The Implementation Reality
Here's where things get complicated. As of now, CSRMC exists as three pages of PDFs and a press release.
The detailed implementation guides - the hundreds of pages that tell you how to actually do this - don't exist publicly yet.
Based on Dion's experience with military policy development, this framework has probably been in development for two to three years already. The full documentation might take another six months to emerge. Until then, nobody can actually implement CSRMC because the instructions don't exist.
There's also the technology challenge. Continuous monitoring requires infrastructure. When Dion's team implemented continuous monitoring for the Navy in 2017, they called it CHAMP (Continuous Hardening and Monitoring Program). It worked, but it required new tools, new processes, and new training. Scaling that across the entire Department of Defense is a massive undertaking.
The data volume alone is staggering into millions of endpoints. Processing that much security telemetry continuously requires serious computational resources and, more importantly, humans who can interpret what it means.
The Practical Challenges
Continuous monitoring sounds great until you consider the operational reality. As Dion explains, automated scanners can report vulnerabilities daily, but if your team can only fix things monthly, you've just created a backlog of noise.
There's also the false positive problem. Every automated scanner generates alerts that aren't real problems. Dion gives an example from his recent coding work. AI will confidently flag a problem, and then promptly back-pedal when the human in a loop calls out a false positive.
The mission impact question is even thornier. If a ship actively engaged in combat operations has a critical vulnerability, do you disconnect it? The framework says yes. Reality says maybe. As Dion notes,
Would you want to disconnect a ship that's in the middle of a war because of a cybersecurity vulnerability? Well, maybe, maybe not. It depends on how vulnerable they are.
What This Means for the Broader Federal Government

The big unknown is whether CSRMC stays confined to the Department of Defense or becomes the new federal standard. RMF came from NIST and applies government-wide. CSRMC comes from DoD (now the "Department of War," though their network is still called DODIN, not yet "DOWIN").
Dion raises an interesting possibility:
"We could, especially under the current political climate and administration we have, see that RMF doesn't go away. And it stays there because NIST wrote it and NIST is going to keep it. And Department of War comes out with their own and says, we're not even going to play with NIST anymore."
This could create a split system where defense contractors follow CSRMC while civilian agencies stick with RMF. That would complicate life for companies working with both sides of government.
The Skills That Matter Now
For cybersecurity professionals, understanding CSRMC early provides an advantage. But the specific skills that matter aren't necessarily new:
Continuous monitoring technologies (SIEM, SOAR, cloud security posture management)
Automated security assessment and validation
Risk-based decision making under uncertainty
DevSecOps and CI/CD pipeline security
These capabilities are already valuable. CSRMC just makes them mandatory for federal work.
The framework also validates a shift that's been happening in commercial cybersecurity for years. Cloud providers already do continuous monitoring. Modern development teams already integrate security into CI/CD pipelines. CSRMC is federal security catching up to commercial practice, not the other way around.
A Realistic Assessment
CSRMC represents genuine progress in federal cybersecurity thinking. The emphasis on continuous monitoring acknowledges that threats don't wait for your next scheduled assessment. The operational focus puts security decisions in the hands of people who understand the systems.
But it's not a magic solution. Continuous monitoring means continuous work. Automated assessment still requires human interpretation. And the fundamental tension between security and mission requirements doesn't go away just because you check things more frequently.
The transition will be messy. Organizations with existing RMF implementations have massive investments in documentation and processes built around the old framework. Retooling for CSRMC will take time, money, and political will.
As Dion observes, the technology exists to do continuous monitoring well. AWS Config, Azure Security Center, and similar tools prove it works at scale. But having the technology and having the people, processes, and culture to use it effectively are different things.
The real test of CSRMC won't be whether it's better than RMF in theory - it almost certainly is. The test will be whether federal organizations can actually sustain the operational tempo that continuous security requires. Because unlike a three-year ATO that lets you rest between certifications, continuous authorization never stops demanding attention.
For now, federal contractors and agencies should pay attention but not panic. Until the full implementation guides emerge, CSRMC remains more promise than practice. But the direction is clear: federal cybersecurity is moving toward continuous, automated, risk-based security management. Organizations that start building those capabilities now will be ready when the framework fully arrives.