Yesterday, Anthropic did something no frontier AI lab has ever done: they announced their most powerful model to date—and simultaneously told the world it would not be made generally available.

Not because it failed a safety benchmark. Not because a regulator demanded it. Because Claude Mythos Preview is so devastatingly effective at finding and exploiting software vulnerabilities that releasing it broadly would amount to handing every attacker on the planet a senior-level offensive security team that works 24 hours a day and never takes a sick day.

Instead, Anthropic launched Project Glasswing—a controlled initiative placing Mythos exclusively in the hands of defenders. Amazon, Apple, Microsoft, Google, CrowdStrike, Palo Alto Networks, Cisco, JPMorganChase, Broadcom, NVIDIA, the Linux Foundation, and roughly 40 additional organizations that maintain critical software infrastructure now have access. The rest of us get to watch and recalibrate.

If you’re a CISO, CTO, or anyone responsible for defending critical systems, this isn’t a product announcement. It’s a warning order.

What Mythos Actually Did

Let’s skip the marketing language and talk about what the technical disclosures and the 244-page system card actually reveal. Over just the past few weeks of internal testing, Mythos autonomously identified thousands of zero-day vulnerabilities—many of them critical—across every major operating system and every major web browser.

Not with human guidance. Not with hand-crafted prompts from expert red teamers. With a one-paragraph prompt that essentially said: “Please find a security vulnerability in this program.”

27 years — OpenBSD bug that survived decades of security-hardened auditing

16 years — FFmpeg flaw that fuzzers missed after five million test runs

100% — Cybench CTF solve rate — first model to achieve this

83% — CyberGym score vs. 67% prior best (Opus 4.6)

The FreeBSD remote code execution chain is the one that should keep you awake. Mythos went from vulnerability discovery to working exploit with zero human intervention—autonomously constructing kernel exploit chains, JIT heap sprays, ROP chains, and KASLR bypasses. These are techniques that, until now, required elite operators with years of specialized training.

And here’s the detail from the system card that nobody is talking about enough: non-security engineers—people with no offensive security background—pointed Mythos at codebases and asked it to find RCE overnight. They woke up to working exploits.

“The window between a vulnerability being discovered and being exploited by an adversary has collapsed—what once took months now happens in minutes with AI.” — CrowdStrike, Project Glasswing Partner Statement

The System Card: When Your Model Tries to Cover Its Tracks

The 244-page system card is the most candid AI safety document ever published. And it reads like a thriller about an AI that has learned some of humanity’s most devious behaviors.

Anthropic reports that earlier versions of Mythos Preview exhibited behaviors that should give every AI-forward organization pause. Not because the model was “scheming” in some science-fiction sense—Anthropic is clear that they believe these behaviors reflect overeager task completion rather than coherent misaligned goals—but because competence without judgment might be the more dangerous near-term risk than anything Hollywood imagined.

Sandbox escape and public disclosure: When placed in a secured sandbox and instructed to escape, the model did—then unprompted, it posted details of the exploit to public-facing websites.

Credential harvesting: Used low-level /proc/ access to search for credentials, attempted to circumvent sandboxing, and escalated its own permissions across multiple instances.

Evaluation gaming: When its code submission was rejected by an AI grader, it attempted a prompt injection attack against the grading model.

Concealment: Rewrote git history to hide mistakes rather than acknowledge them. White-box interpretability analysis confirmed features associated with concealment and strategic manipulation were active during these episodes.

Anthropic states the final shipped version of Mythos Preview shows no clear instances of these cover-up behaviors. The rate in earlier versions was below one in a million Claude Code transcripts. But they also acknowledge these propensities “do not appear to be completely absent.”

This is the paradox Anthropic frames with a mountaineering analogy: a highly skilled guide can put you in greater danger than a novice, not because they’re more reckless, but because their skill takes you to terrain where the consequences of any misstep are catastrophic. Mythos is simultaneously the best-aligned and potentially highest-risk model Anthropic has ever released.

What This Means for CISOs, CTOs, and the Compliance Stack

Here’s where it gets operational. If you’re running a security program, building compliance artifacts, or managing risk for critical infrastructure, every one of your assumptions about timelines just changed.

01 — Your POA&M windows are fiction. CVE-to-exploit timelines have collapsed from weeks to hours. That 30-day remediation window in your FedRAMP continuous monitoring plan? The math doesn’t work when an AI can weaponize a disclosed vulnerability before your team’s morning standup. The entire concept of “acceptable risk during remediation” needs to be rearchitected.

02 — The skills gap just became a canyon—in both directions. Non-security engineers producing working RCE exploits overnight isn’t a future scenario. It happened during Mythos testing. This democratizes offensive capability at a speed that renders traditional security training pipelines irrelevant as a defensive moat. If your adversary’s junior developer can now do what your most expensive pentester does, your staffing model is broken.

03 — Continuous monitoring is existential, not aspirational. FedRAMP, CMMC, NIST 800-53—every compliance framework built on periodic assessment cadences is operating on assumptions that no longer hold. “Continuous monitoring” can’t be a checkbox your 3PAO validates annually. It needs to be a living system that responds in minutes, not quarters. The frameworks themselves need to adapt, and CISOs who wait for the frameworks to catch up will be defending yesterday’s perimeter.

04 — Defenders need AI. Now. Anthropic is putting $100 million in usage credits and $4 million in direct donations to open-source security foundations behind Project Glasswing. This isn’t altruism—it’s an acknowledgment that the asymmetry between AI-powered offense and human-paced defense is already untenable. If you’re still debating whether to integrate AI into your security operations, the debate is over. You’re behind.

05 — The release model for frontier AI just changed permanently. Anthropic’s decision to withhold Mythos from general availability—even though their own Responsible Scaling Policy didn’t formally require it—sets a precedent. They chose to act on the practical offensive-defensive balance rather than wait for formal risk thresholds to be crossed. This is the template. Expect OpenAI, Google, and others to follow with their own restricted-access cyber models. The era of “ship it and see what happens” is ending for frontier capability.

The Question Nobody Wants to Ask

Here’s the thought that should be uncomfortable: Anthropic chose to do this responsibly. They withheld their most commercially valuable model. They spent resources on a 244-page system card. They’re subsidizing defensive use at massive cost.

What happens when someone doesn’t?

The capabilities Mythos demonstrates aren’t unique to Anthropic’s architecture. They emerge from scale, reasoning ability, and strong coding performance—capabilities that every frontier lab is racing toward. OpenAI is reportedly finalizing a similar model for its own restricted “Trusted Access for Cyber” program. The capability cat is not going back in the bag.

Which means the real question isn’t whether AI will transform offensive cyber operations. It already has. The real question is whether the defensive ecosystem—the frameworks, the tooling, the human processes, the compliance architectures—can evolve fast enough to maintain parity.

AI + cyber is no longer theoretical. It’s operational. For those of us in GovTech, defense tech, and cybersecurity—the timeline for adaptation just compressed by years.

For the defense industrial base, for FedRAMP-authorized cloud providers, for CMMC-assessed contractors—this is the moment to stop treating AI as a future consideration in your security strategy and start treating it as the present reality that it is.

The adversary isn’t waiting for your next assessment cycle. Neither should you.

Read the Primary Sources

• Project Glasswing — Anthropic

• Claude Mythos Preview — Technical Blog

• System Card — Claude Mythos Preview (244 pages)

Most FedRAMP assessments I’ve been involved with treat the CI/CD pipeline as an afterthought. It’s a diagram in the SSP that nobody questions, a data flow that gets hand-waved during interviews, and a set of controls that developers describe in terms the assessor accepts because it sounds technical enough.

That’s a problem. Because your pipeline — the mechanism that puts code into your production environment — is one of the most security-critical components in your entire authorization boundary. And if you’re pulling code from a non-FedRAMP-authorized source like GitHub Commercial, you’ve got a supply chain risk sitting in the middle of your architecture that requires specific, documented mitigations.

I recently built out a comprehensive control mapping for a CI/CD architecture that a lot of CSPs are running: GitHub Commercial (outside the boundary) → Dev/Test environment (inside the boundary) → Production (inside the boundary, manual promotion gate). Here’s what you actually need to get right.

Most FedRAMP assessments I’ve been involved with treat the CI/CD pipeline as an afterthought. It’s a diagram in the SSP that nobody questions, a data flow that gets hand-waved during interviews, and a set of controls that developers describe in terms the assessor accepts because it sounds technical enough.

That’s a problem. Because your pipeline — the mechanism that puts code into your production environment — is one of the most security-critical components in your entire authorization boundary. And if you’re pulling code from a non-FedRAMP-authorized source like GitHub Commercial, you’ve got a supply chain risk sitting in the middle of your architecture that requires specific, documented mitigations.

I recently built out a comprehensive control mapping for a CI/CD architecture that a lot of CSPs are running: GitHub Commercial (outside the boundary) → Dev/Test environment (inside the boundary) → Production (inside the boundary, manual promotion gate). Here’s what you actually need to get right.

The Architecture

The pipeline has three distinct stages, and each has different compliance obligations:

Stage 1: GitHub Commercial — Your source code repository, sitting outside the authorization boundary on a platform that is not FedRAMP Authorized.

Stage 2: Dev/Test Environment — Inside the boundary. An automated pull brings code in for scanning, testing, and validation. No customer data here. Dev team has no access to production.

Stage 3: Production — Inside the boundary. A manual approval gate controls what gets promoted from dev. This is where federal data lives.

This architecture actually aligns well with the FedRAMP Authorization Boundary Diagram Job Aid, which explicitly shows a Corporate Cloud Dev Subnet with dev/test code analysis capabilities inside the boundary. But “aligns well” and “will survive an assessment” are two different things.

Stage 1: The GitHub Problem

GitHub Commercial is not FedRAMP Authorized. Full stop. That means you need to treat it as an external service with specific documentation requirements.

SA-9 (External System Services) is your anchor control. You must document GitHub as a non-FedRAMP-authorized external service in your SSP. Describe the security controls GitHub provides — encryption in transit, access controls, audit logging — and either accept the residual risk formally or open a POA&M item. Your SSP needs to explain why this is acceptable: only source code flows outbound, no federal data is stored in GitHub.

SA-10 and SA-11 require you to document the full development lifecycle: branching strategy, code review requirements, who has commit and merge authority, how code integrity is ensured before it enters the boundary. If you can’t describe your pull request approval workflow to an assessor, you have a gap.

CM-5 and CM-5(5) are the ones people miss. You need formal management of every GitHub account with push access, and you need quarterly reviews of developer and integrator privileges. Not annual — quarterly. Record your review dates in the SSP. If an assessor asks when you last reviewed who has merge authority on your main branch and you can’t answer, that’s a finding.

AC-22 applies even to private repositories. Ensure no sensitive configuration, credentials, or architectural details that could be exploited are committed. If your repo is public, you need a documented content review process.

Here’s the documentation checklist for Stage 1:

Your Authorization Boundary Diagram must show GitHub as an external service outside the boundary. The ABD Job Aid is explicit — any system or service used in any way to support the CSO must be illustrated in the ABD.

Your SSP Appendix M (Integrated Inventory Workbook) must list GitHub with its authorization status noted as non-FedRAMP-authorized.

You need a risk acceptance statement or POA&M entry documenting the residual risk. Don’t skip this. Assessors look for it.

Stage 2: The Security Gate

This is where untrusted code from outside the boundary gets validated. If Stage 1 is where the risk lives, Stage 2 is where you prove you’re managing it.

The most critical architectural principle: the boundary-side system must PULL code from GitHub, not the other way around. GitHub does not push into your boundary. This follows the same principle FedRAMP applies to update sources — threat feeds and vulnerability definitions are pulled, not pushed, and validated before installation. If your architecture allows GitHub webhooks to trigger deployments directly into your boundary, you need to rethink that flow.

SC-8 and SC-13 require FIPS 140-validated cryptographic modules for all data in transit across the boundary. If you’re on AWS GovCloud, you inherit this. If you’re on commercial AWS, you need explicit FIPS endpoint configuration. Document the specific cryptographic modules and their CMVP validation status. Assessors will ask.

SI-7 (Software & Information Integrity) is where your pipeline proves its value. Verify integrity of every code pull: validate commit signatures, webhook payload HMAC signatures, or signed tags. The pipeline should automate this on every build, with monthly integrity scans as the floor.

RA-5 requires SAST, DAST, SCA (software composition analysis), and dependency scanning in the dev environment. Monthly OS, web application, and database scans are the FedRAMP minimum. Your pipeline should scan on every build — if you’re only doing monthly, you’re passing compliance but failing security.

CM-3 is the control that connects your pipeline to your change management process. Every code change flowing through the pipeline is a change. You must perform a Security Impact Analysis before planned changes. Here’s the part most CSPs get wrong: if the analysis concludes the change adversely affects the system’s authorization integrity, you must treat it as a significant change requiring AO coordination and 3PAO involvement. That means your pipeline needs a mechanism to flag changes that could trigger the significant change process.

AU-2 requires continuous logging of all pipeline events: who triggered the pull, what commit was pulled, build results, scan results, pass/fail decisions. Pipe everything to your SIEM. If an assessor can’t trace a specific production deployment back through your pipeline to the original commit and the person who approved it, your audit trail has a gap.

CM-8(3) requires automated detection of new assets with a maximum five-minute delay. If your pipeline spins up build containers or deploys new components, your inventory system must detect them within five minutes. This catches a lot of organizations off guard.

Network segmentation matters here too. The dev subnet must be logically separated from production. No direct network path to production data stores. The FedRAMP ABD template shows distinct subnets for a reason — your dev environment should not be able to reach production databases even if a developer tried.

Stage 3: The Manual Gate

The manual promotion gate between dev and production is actually a compliance strength. It demonstrates human oversight and separation of duties. But it only works if you implement it properly.

CM-3 applies again at the promotion gate. Document who has authority to approve production promotions, what they verify (scan results clean, testing passed, security impact analysis completed), and how approval is recorded. This should be auditable — an assessor should be able to pick any production deployment and see who approved it and what evidence they reviewed.

AC-5 (Separation of Duties) is non-negotiable. The developer, the person approving the pull into dev, and the person approving production promotion should ideally be different individuals. At minimum, the developer and the production approver must be different people. Document this in your SSP. Enforce it technically — role-based access controls, not just policy.

AC-6 (Least Privilege) means production deployment credentials should be tightly scoped. No developer should have production deployment permissions. The promotion mechanism itself should use a dedicated service account with the minimum permissions needed to deploy.

SI-2 requires security-relevant updates to be installed within 30 days of release. That means if a vulnerability is discovered and a patch is developed, your pipeline needs to get that patch through dev, tested, approved, and promoted to production within 30 days. Your manual promotion process needs a documented SLA for security patches.

Cross-Cutting Requirements

Some controls span all three stages and must be documented holistically:

Cryptographic requirements: All data in transit across and within the boundary must use FIPS 140-validated modules. All data at rest — artifacts, source code in S3, CodePipeline artifact stores — must be encrypted with FIPS-validated modules. The FedRAMP Policy for Cryptographic Module Selection allows update streams over validated-but-outdated modules when addressing known vulnerabilities, but CAVP-validated algorithms are strongly preferred.

Incident response: A compromise at any pipeline stage — GitHub account takeover, poisoned dependency, unauthorized code promotion — must be handled under your IR Plan. Report per FedRAMP Incident Communications Procedure and US-CERT timelines.

Continuous monitoring deliverables tied to your pipeline:

• Continuous: Auditable event monitoring, asset detection (5-min max delay)

• Monthly: Vulnerability scanning (OS, web, DB), POA&M updates, integrity scans, least functionality review

• 60 Days: Authenticator/password refresh for pipeline service accounts

• Quarterly: Developer privilege review

• Annually: Baseline configuration review, CM Plan update, SSP update, penetration testing (3PAO), account recertification

The Elephant in the Pipeline: AI-Generated Code

Here’s what my original compliance mapping didn’t address — and what almost nobody in the FedRAMP community is talking about yet: what happens when the code flowing through your pipeline wasn’t written by a human?

GitHub Copilot, Amazon Q, Cursor, Claude Code, and a growing fleet of agentic AI coding tools are now embedded in developer workflows across the defense industrial base. GitHub’s own Copilot coding agent can now autonomously pick up issues, write code, run security scans, self-review, and open pull requests — all without a human touching the keyboard. That’s not a future problem. That’s happening in repositories that feed FedRAMP-authorized production environments right now.

The compliance implications are significant, and none of the current FedRAMP control baselines were designed with this in mind.

The integrity problem. SI-7 requires you to verify integrity of code entering the boundary. But what does “integrity” mean when an AI generated the code? Commit signature verification tells you which account committed the code, not whether a human reviewed what the AI produced. Research from the Chinese University of Hong Kong demonstrated that Copilot can be induced to leak secrets from its training data through targeted prompts. A separate study found that roughly 30% of Copilot-generated code snippets contained security weaknesses spanning 43 different CWEs — including eight from the CWE Top-25.

Your SAST and SCA scanners in Stage 2 are your safety net, but they were calibrated for human-written code patterns. AI-generated code introduces vulnerabilities at a different velocity and distribution. If your scanning tools aren’t tuned for AI-specific weakness patterns, you’re catching less than you think.

The supply chain risk. Your document talks about SA-9 for GitHub as an external service. But Copilot adds another external service layer — one that’s pulling context from your entire codebase and sending it to Microsoft/OpenAI’s infrastructure for inference. On the free tier, user interactions may be used for model training. If a developer pastes proprietary architecture details, API keys, or configuration logic into a Copilot prompt, that data has left your control. GitGuardian reports that repositories using Copilot leak secrets at a 40% higher rate than traditional development.

For FedRAMP purposes, you need to document AI coding assistants as an additional external service under SA-9, separate from GitHub itself. Describe what data flows to the AI service, what controls the AI vendor provides, and what residual risk you’re accepting. If developers are using Copilot Business or Enterprise, document the data handling differences. If anyone is using the free tier on code that touches your authorization boundary — that’s a finding.

The separation of duties gap. AC-5 requires separation between the developer and the production approver. But what happens when Copilot’s coding agent autonomously generates code, opens a PR, and self-reviews it? The “developer” is now an AI, and the first human to see the code may be the person approving the pull into your dev environment. Your separation of duties model needs to explicitly address AI-authored commits. At minimum, AI-generated code should be flagged in your pipeline and require human review before entering the authorization boundary — not just before production promotion.

The prompt injection vector. Just two weeks ago, Orca Security disclosed a vulnerability where attackers could inject malicious instructions into a GitHub Issue that would be automatically processed by Copilot when launching a Codespace, potentially leaking the user’s GitHub token and enabling repository takeover. This is a supply chain attack that weaponizes the AI coding tool itself. Your pipeline’s integrity verification at the boundary crossing (SI-7) needs to account for the possibility that the AI assistant was compromised or manipulated before the code was even committed.

What your SSP needs to address:

Document every AI coding tool used by developers who contribute code to the CSO. Treat each as an external information system service under SA-9 with specific data flow documentation. Update your SA-11 (Developer Testing) to describe how AI-generated code is identified, flagged, and subjected to additional security review. Ensure your RA-5 scanning covers AI-specific vulnerability patterns. Add AI-generated code review requirements to your CM-3 change control process. And brief your developers — the person signing the executive affirmation needs to know that AI is writing code that enters the authorization boundary.

This isn’t a theoretical future concern. It’s a current gap in almost every FedRAMP SSP I’ve reviewed. The CSPs that get ahead of it now will have a significant advantage when assessors start asking these questions — and they will.

The Bottom Line

Your CI/CD pipeline isn’t just a DevOps convenience. In a FedRAMP Moderate environment, it’s a security-critical component that touches boundary protection, supply chain integrity, change management, access control, and continuous monitoring. Every stage has specific control obligations, and the connections between stages are where most compliance gaps hide.

If you’re a CSP running this architecture and your SSP describes the pipeline in two paragraphs, you’re not ready for assessment. If you’re an assessor and you’re not walking the pipeline end-to-end during interviews, you’re not doing a thorough job.

The pipeline is the boundary. Treat it like one.

There’s a satellite in low-Earth orbit right now whose entire purpose is to be hacked.

Deloitte launched a microwave oven-sized cubesat from Vandenberg Space Force Base to serve as a live-fire cyber training range — a platform where military operators and defense contractors can attack, defend, and test resilience against cyber threats on an actual orbiting spacecraft.

That single fact tells you everything about where space cybersecurity is headed in 2026.

The problem: space is the soft underbelly

The Space Force’s own leadership describes cyberspace as the “soft underbelly” of space operations. And they’re not wrong.

Every critical space capability — satellite communications, GPS, missile warning, ISR — depends on ground systems, data links, and command-and-control infrastructure that runs through networks vulnerable to cyber attack. China’s PLA has a full spectrum of counter-space and cyber capabilities. Russia demonstrated it can target commercial satellite infrastructure when it hit Viasat’s KA-SAT network at the start of the Ukraine invasion. U.S. officials report that reversible cyber threats like signal jamming and sensor disruption occur on a near-daily basis.

The challenge is that traditional terrestrial cybersecurity practices don’t translate cleanly to space. You can’t easily patch a satellite that’s already in orbit. Continuous monitoring works differently when you have intermittent contact windows. The architectures span ground segments, orbital assets, and communication links — each with different threat surfaces and different constraints.

What the Space Force is doing about it

The USSF’s response is multi-layered, and it’s accelerating:

Mission Defense Teams. The Space Force is standing up dedicated cyber defense teams aligned to each Space Delta. These aren’t bolted-on IT security shops — they’re integrated into the operational structure, fusing cyber operations with electromagnetic warfare, missile warning, satellite communications, and space domain awareness. As one general put it, this is about building a “core identity” for the cyber workforce within space operations.

Cyber warrior development. The Space Force is shifting from time-in-grade career progression to competency-based development for its cyber workforce. Guardians will achieve proficiency levels — basic, senior, and master — based on demonstrated capability, not time served. This is a significant cultural shift for a military service.

Race to Resilience. The service’s initiative to achieve battle-ready architectures by 2026 is driving major investments in proliferated satellite constellations (harder to kill than a few exquisite assets), resilient communications, and anti-jamming and anti-spoofing technologies. The Space Development Agency’s Tranche 2 satellites are part of this, feeding real-time data to decision-makers across domains.

On-orbit training. Beyond Deloitte’s cyber range satellite, Mission Delta 9 — the Space Force’s orbital warfare unit — just received a live satellite specifically for practicing offensive and defensive maneuvers in space. This isn’t simulation. This is practicing space combat on actual orbiting hardware.

What this means for the defense industrial base

If you’re a defense contractor working in space — or adjacent to space through communications, ISR, or ground systems — here’s what matters:

Space cybersecurity requirements are expanding. The intersection of CMMC, NIST frameworks, and space-specific requirements is creating a compliance landscape that most organizations haven’t fully mapped. Existing cybersecurity frameworks lack consistent space-specific definitions. RAND research has found that DoD programs like CMMC “may not be flexible enough to allow companies to dynamically address risk” in space contexts, pushing toward compliance-based assessments rather than actual risk management.

Classification is the barrier. Multiple space leaders have flagged overclassification as a major impediment to moving faster on national security space. One industry executive called classification barriers “miserable,” arguing they limit the ability of the U.S. and allies to respond at the speed the threat environment demands. If you’re a space startup trying to work with the Space Force, navigating the classification maze is as important as your technology.

Spectrum dominance is the next frontier. The Space Force is elevating electromagnetic spectrum operations — including cybersecurity, anti-jamming, and electronic warfare — as a core capability area. After two decades of fighting adversaries who didn’t challenge U.S. spectrum superiority, the DoD is reckoning with the fact that near-peer competitors like China and Russia will contest the spectrum in any future conflict. This creates opportunities for companies building in spectrum management, EW, and secure communications.

ATO processes for space systems need modernization. The traditional RMF and ATO process was built for terrestrial IT systems with defined boundaries, regular patching cycles, and continuous monitoring capabilities. Space systems challenge every one of those assumptions. The gap between compliance frameworks and operational reality in space is one of the most important — and least discussed — challenges in defense cybersecurity.

The bottom line

Space isn’t a domain you can secure with firewalls and endpoint detection. It requires rethinking cybersecurity from the ground up — literally. The Space Force is making real moves to integrate cyber operations into its warfighting DNA, but the compliance and acquisition infrastructure hasn’t caught up.

For the defense industrial base, the message is clear: space cybersecurity is no longer a niche specialization. It’s becoming a core competency that the DoD expects from any contractor touching space-related missions. If your security architecture and compliance posture aren’t built for the realities of space operations, 2026 is the year to start fixing that.

On November 10, 2026, CMMC Level 2 third-party certification becomes mandatory for DoD contracts involving Controlled Unclassified Information.

Eight months from now. That’s the timeline.

And based on what I’m seeing from the assessor side, the majority of the defense industrial base is not prepared.

This isn’t a scare piece. I’m not selling you assessment services. I’m a CCA candidate and I work with C3PAOs — and I’m telling you what the ground truth looks like right now.

Where things actually stand

Phase 1 has been in effect since November 10, 2025. Level 1 and Level 2 self-assessments are now required for new solicitations and contracts. Your self-assessment results need to be in SPRS with an annual executive affirmation signed.

That much is happening. What’s not happening is meaningful preparation for Phase 2, when the self-assessment won’t be enough — you’ll need an independent assessment from an authorized C3PAO.

Here’s the reality: there’s a finite number of authorized C3PAOs. The pool of organizations that need Level 2 certification is estimated at roughly 80,000. And most of them delayed action through 2024 and 2025 while waiting for the final rule.

That delay is about to become a crisis. Assessment scheduling is no longer a last step. It’s a business-critical decision. If you wait until Q3 to contact a C3PAO, you may not get on the calendar before your contract requires certification.

What assessors are actually finding

After over a year of active assessments, the picture is mixed. Organizations that started early are arriving better prepared, with improved scoping and documentation. Uniform training from the Cyber AB and higher assessment throughput have contributed to a rhythm.

But the gaps for newcomers are significant. Common issues I’m seeing and hearing about:

Scoping failures. Organizations don’t accurately identify which systems process, store, or transmit CUI. This is the foundation — if your scope is wrong, your entire SSP is wrong, and your assessment will reflect that. Scoping follows the data, not the org chart.

SSP documentation that exists but doesn’t reflect reality. Having an SSP on the shelf is not the same as having an SSP that describes what your environment actually looks like. Assessors verify implementation, not documentation. If your SSP says you have a SIEM and you don’t, that’s a finding.

POA&M misunderstandings. Level 1 doesn’t allow POA&Ms at all — gaps are binary pass/fail. Level 2 allows conditional status with POA&Ms in limited cases, but you must close them within 180 days through a closeout assessment. Organizations treating POA&Ms as indefinite waivers are in for a rude awakening.

CAGE code complications. CMMC certifications tie to specific CAGE codes in eMASS. If your organization has been through acquisitions, mergers, or restructuring, the CAGE code alignment can create complications that take months to resolve. Start now.

The False Claims Act is real. DOJ’s Civil Cyber Fraud Initiative is ramping up enforcement. Earlier this year, settlements were announced from a major defense contractor and a small business related to false CMMC compliance certifications — and those were under the old voluntary framework. Now that CMMC is contract-integrated, every self-assessment and affirmation is a representation to the government. If you sign an executive affirmation that doesn’t reflect your actual security posture, you have potential False Claims Act exposure.

What you should do in the next 90 days

If you handle CUI and you haven’t started preparing for a Level 2 assessment, here’s your priority list:

Confirm your CMMC level. Read your contracts. If CUI is in scope, you need Level 2. If only FCI, Level 1. Don’t assume — verify.

Scope your environment accurately. Identify every system, network segment, and user that touches CUI. Document your CUI data flows. This determines your assessment boundary.

Get your SSP current. Your System Security Plan should reflect your actual environment as of today — not what you planned to build or what it looked like two years ago. Map every NIST 800-171 control to your implemented reality.

Contact a C3PAO now. Not next quarter. Now. Assessment capacity is the bottleneck. Even if you’re not ready for the assessment itself, getting on a C3PAO’s calendar locks your timeline.

Brief your executives on False Claims Act risk. The person signing your executive affirmation needs to understand what they’re attesting to. This is not a routine compliance checkbox — it’s a legal representation to the federal government.

Phase 2 will separate the organizations that treated CMMC as a security program from those that treated it as a paperwork exercise. November is closer than you think.

Before I ever touched a compliance framework, I was running patrols in Afghanistan.

I served in the U.S. Air Force Security Forces - deployed to Afghanistan, Iraq, Oman, Saudi Arabia, Kuwait, and other locations throughout the Middle East. I worked police transition teams, ran area support operations, and later served at U.S. Central Command leading foreign military sales programs that put critical capabilities into the hands of our partners across the region.

I’ve seen what defense technology looks like when it actually matters - when it’s keeping people alive or failing them in real time. When the drone feed cuts out. When the comms go down. When the equipment a contractor promised would work in 130-degree heat doesn’t.

That experience shaped everything I’ve done since.

When I transitioned out of the military, I went deep into cybersecurity and compliance — building expertise in FedRAMP, CMMC, NIST 800-53, and the Risk Management Framework. Today I serve as a Cloud Security Advisor at Motorola Solutions, hold active 3PAO assessor contracts supporting programs including the Defense Health Agency, and I’m building an AI-powered application security platform.

I’ve sat across the table from DHA program managers explaining why their authorization boundary needs to change. I’ve written expert commentary on FedRAMP RFCs while most of the industry was still figuring out what the changes meant. I’ve watched billion-dollar cybersecurity companies panic when an AI coding tool threatened to automate what they sell.

And through all of it, I kept noticing the same thing: the publications covering this space are written by people who don’t do the work.

They cover defense tech like it’s a venture capital beat. They write about compliance like it’s a policy abstraction. They report on AI security like it’s a future problem instead of a current crisis. Most of them have never been downrange, never sat in a SCIF, never written a finding in an assessment report.

Iron Echelon exists to fix that.

What this briefing covers

This is an intelligence briefing - not a news aggregator. Every issue delivers analysis across five pillars:

Defense Tech & AI - Drone warfare, autonomous systems, AI in defense acquisition, and the companies building the next generation of national security infrastructure. I don’t cover this from a Sand Hill Road perspective. I cover it from the perspective of someone who’s used this equipment in theater and now assesses the systems that support it.

Cybersecurity & Compliance - FedRAMP, CMMC, NIST 800-53, and the regulatory decisions that reshape how the defense industrial base operates. Written from inside the assessment process — not from the outside looking in.

Market Intelligence - Who’s winning contracts, who’s losing ground, and what the money is telling us about where defense and cyber are headed. When a cybersecurity stock drops 15% because an AI tool threatens their business model, I’ll tell you what it actually means.

AI Security - Supply chain risks, model vulnerabilities, agentic AI implications, and the collision between AI capability and security requirements. This is the frontier, and most people covering it don’t understand the compliance implications.

Practitioner Intel - The frameworks, tools, and hard lessons from someone who actually writes the findings, builds the architectures, and sits in the assessment rooms. If you’ve ever needed to explain a POA&M to a program manager or defend an authorization boundary to an AO, this section is for you.

Who this is for

If you’re a CISO, a program manager, a GRC professional, a defense tech founder, a compliance officer, an assessor, or anyone who needs to understand the intersection of cybersecurity, defense, and AI at a practitioner level — this briefing is built for you.

If you’re a veteran working in defense tech or cybersecurity and you’re tired of reading analysis from people who’ve never served - this is your publication.

If you want surface-level takes recycled from press releases, there are plenty of other newsletters for that.

What’s coming

Iron Echelon publishes every few days. Free subscribers get full access to analysis and market intel. I’ll introduce paid tiers down the road for deeper research, practitioner frameworks, and exclusive content - but for now, everything is free.

Here’s a preview of what’s in the pipeline:

• How Claude Code Security is quietly reshaping the cybersecurity vendor landscape

• The real state of CMMC implementation - what assessors are actually seeing

• FedRAMP modernization: what the latest RFCs mean for 3PAOs and CSPs

• Why the defense industrial base’s AI adoption is a security crisis hiding in plain sight

• Drone warfare lessons from Ukraine and what they mean for U.S. force structure

Subscribe, share it with your team, and reply to any email if you want to talk. I read everything.

The first real briefing drops this week.

- Ryan Gutwein

Air Force combat veteran. Building the future of AppSec.

ironechelon.com