FedRAMP 20x Defending the Mission Isn't a Feature. It's an Operating Model.

What continuous defense actually looks like when it's built into operations not bolted on beside them. Updated based on FedRAMP CR26.

There's a version of security that looks good on paper and falls apart at 2 a.m. on a Tuesday.

It has a binder full of controls. A completed risk register. A polished system security plan. What it doesn't have is anyone watching when something goes wrong.

We've spent nearly two decades working with federal agencies and commercial customers who thought they had security covered because they had compliance covered. Those aren't the same thing. They weren't then, and they're especially not the same thing now.

The threat environment doesn't respect authorization boundaries. Adversaries don't check whether your FedRAMP package is current before they move. They probe, they persist, they wait. And when your monitoring is a monthly scan and your response is a vulnerability record entry sitting in a queue waiting for the next review cycle, you're not defending anything. You're documenting the aftermath.

That's the problem Defend is designed to fix.

Build. Operate. Prove. Defend. The last part is where it gets real.

The InfusionPoints Continuous Trust Platform (CTP) is organized around a continuous engine: Build, Operate, Prove, Defend. Not a service menu. Not four separate engagements. A single loop where each stage feeds the next and trust is demonstrated at every point in the lifecycle.

Build is about designing systems with security from the start on a pre-authorized, hardened foundation. Architecture that doesn't require a compliance retrofit six months before authorization. Operate is about keeping those systems current, patched, and running in a state that matches the documentation. Prove is about generating continuous, automated evidence that the controls are working as designed. And Defend is about what happens between the builds and the audits, which is most of the time.

Defend is the operating rhythm of a mature security organization. It's the analysts watching alerts at 3 a.m. It's the persistent, automated detection that fires when a new vulnerability drops, evaluates whether it's exploitable in this environment, and routes it to the right response. It's the incident response team that knows your environment before they need to act in it. It's the VDR and VER engine that generates continuous vulnerability records and contextual evaluations as a byproduct of staying secure, not a separate effort staffed up for the next assessment.

Most organizations don't have that. They have point-in-time coverage and a help desk ticket when something looks wrong.

What we actually see in the field

Here's what a typical environment looks like when we come in:

• Vulnerability scans running monthly, or less frequently, against systems that change daily.

• A SIEM ingesting logs that nobody is reviewing unless an alert fires, and alert thresholds tuned so conservatively that most real events don't fire.

• An incident response plan that hasn't been tested and references tools or roles that no longer exist.

• A vulnerability record list that serves as the de facto security roadmap. Under FedRAMP's new VDR framework, CSPs are no longer expected to maintain a POA&M spreadsheet for tracking vulnerabilities. They're expected to maintain current vulnerability records continuously. Most organizations we come in to haven't made that shift. Their roadmap is still a list of known failures, now just called something different.

• No clear answer to the question: if something is happening in this environment right now, how long until someone knows?

That last question is the one that separates organizations that are defending from organizations that are hoping. Mean time to detect is a real metric. In a poorly instrumented environment, it's measured in weeks or months. For a motivated adversary, that's more than enough time.

What VNSOC360° actually does

Our Virtual Network and Security Operations Center (VNSOC360°) is the operational engine behind Defend. It's staffed by U.S. citizens operating on U.S. soil, 24x7x365, monitoring the environments we're contracted to protect.

That matters for federal customers. It's not a marketing point. It's a requirement in most DoD, DHS, and intelligence community environments, and it's something that eliminates a whole category of vendors before the conversation starts.

What VNSOC360° delivers in practice:

Continuous threat detection. We deploy sensors across on-premise, hybrid, and cloud infrastructure and feed them into a SIEM with alert logic tuned to your environment. Not generic templates. Your environment. That specificity is the difference between alert fatigue and signal.

Managed Detection and Response (MDR). When something suspicious surfaces, analysts investigate. Not tools alone. People with context about your systems, your mission, and your risk tolerance. They distinguish noise from threat and act accordingly.

Endpoint Detection and Response (EDR). Endpoint coverage that monitors system activities and events where most attacks ultimately land: on a workstation, a server, a cloud instance. EDR gives us visibility at the execution layer, which is where most detections without endpoint coverage arrive too late.

Identity and access monitoring. Identity is where the perimeter actually lives now. Monitoring privileged access, lateral movement, and anomalous authentication behavior is as important as any network sensor, and in cloud-native environments it's often more important.

Incident response that starts from knowledge, not from scratch. When an incident requires escalation, our team already knows your environment. That's not a luxury. It's a force multiplier. The organizations that suffer the worst outcomes from breaches are the ones whose IR team is spending the first 48 hours learning what they're looking at.

Actionable threat intelligence. Detection without context is just noise. VNSOC360° integrates current threat intelligence into our monitoring operations so analysts aren't just watching alerts in isolation. They're correlating what they see against the actual threat landscape: active campaigns, known adversary TTPs, indicators of compromise relevant to federal and defense industrial base environments, and intelligence specific to the sectors our customers operate in.

That intelligence layer changes what analysts do with a finding. A suspicious authentication event looks different when you know an adversary group has been targeting credential-based access in your sector this week. A lateral movement pattern looks different when you can map it against known TTPs for a campaign that's been active in GovCloud environments. Intelligence doesn't replace human judgment. It sharpens it.

Without that context, analysts are reacting to events in a vacuum. With it, they're making better decisions faster, distinguishing targeted activity from opportunistic noise, and escalating the right things at the right time. That's the difference between a SOC that generates tickets and a SOC that generates outcomes.

VDR and VER are the new operating model. ConMon-as-a-Service is how we deliver them.

Continuous monitoring has always been a regulatory requirement for FedRAMP-authorized CSPs. CR26 didn't change that. What it changed is the standard those CSPs are monitored against.

VDR and VER are not a layer on top of ConMon. They replace the old monthly scan, assemble, submit cycle entirely. Three changes define the shift: CSPs no longer maintain a POA&M for vulnerability tracking, that responsibility now belongs to the agency. Vulnerability evaluation must be contextual, not categorical, assessing internet reachability, exploitability, automation potential, and mission impact for every finding. And detection must be persistent, not periodic. VDR-CSO-DET requires systematic, persistent, and prompt discovery. An environment scanned monthly has 29 days of undetected exposure between cycles. Under VDR, that's a compliance failure, not just an operational gap.

Our ConMon-as-a-Service offering is the delivery vehicle for VDR and VER. Persistent scanning through AWS Inspector, continuous control evaluation through Config, real-time aggregation through Security Hub, and vulnerability record management through Command Center replace the monthly manual assembly model CR26 is retiring.

For the full breakdown of what VDR and VER require operationally, how BOD 26-04 drove the December 7, 2026 mandatory adoption deadline, and what the grace period through March 7, 2027 means for your program, read our dedicated post: https://infusionpoints.com/blogs/fedramp-vdr-ntc-0014-cisa-bod-26-04

VDR compliance without a SOC is still just compliance

Here's a distinction that doesn't get talked about enough. Meeting FedRAMP's VDR requirements and having a 24x7 SOC are not the same thing. Confusing the two is one of the most expensive mistakes in federal security.

VDR tells you what vulnerabilities exist, how exploitable they are, and what action is required within what timeframe. It answers the compliance question: is the vulnerability detection and response posture meeting the current standard? That's valuable. It's also still backward-looking relative to active threats.

A 24x7 SOC answers a different question: is something happening in this environment right now?

Those are fundamentally different problems. An organization with ConMon and no SOC knows their vulnerability record status and their pending remediation items. They do not know if an adversary is moving laterally through their environment at this moment. They won't know until the next scan cycle runs, or until the breach surfaces in a way they can't ignore.

This gap is more dangerous than most organizations realize because VDR compliance creates the same false sense of coverage that ConMon compliance always did. A clean vulnerability record feels like security. A finding evaluated as low exploitability feels like a win. Neither of those things means an active threat isn't present in the environment at this moment.

We've worked with customers who had rigorous ConMon programs, strong audit histories, and zero visibility into active threats. They were compliant and exposed simultaneously. The adversary doesn't care about your last scan cycle. They care about what's accessible right now.

The organizations most likely to have a security event they don't know about are the ones relying on ConMon alone. Persistent detection, by definition, still has gaps without active human monitoring. Between detection events, between vulnerability evaluations, between reporting cycles, the environment is operating without active watch. For a patient adversary, that window is opportunity.

Running ConMon without a SOC is like locking the building at night and never checking the cameras. The locks are real. The gap is real too.

How AI is accelerating VDR, VER, and SOC operations

Artificial intelligence is reshaping how VDR and SOC operations work, and not in the way most vendors describe it. The pitch you hear most often is automation: AI handles the alerts so your analysts don't have to. That framing understates what's actually happening and sets the wrong expectations.

The more accurate framing is this: AI makes persistent, contextual vulnerability detection and response operationally sustainable at scale. VDR requires evaluating every detected vulnerability against four contextual variables. VER requires reporting on that evaluation quickly. Without AI-assisted analysis, those requirements create a workload that outpaces human capacity in most environments.

In a traditional security operation, analyst capacity is the constraint. When alert and finding volume exceeds that capacity, analysts triage based on urgency signals rather than full context. Low-severity findings go uninvestigated. Patterns that span multiple findings go unconnected. Adversaries who understand this operate specifically in the noise.

AI changes that calculus in four concrete ways we're applying inside VNSOC360° and our VDR/VER delivery:

Alert triage and correlation at scale. AI models can process thousands of events simultaneously, correlate signals across data sources that no analyst could manually join in real time, and surface the subset that merits human review. That means analysts spend their time on the things that matter, not on validating that routine events are routine.

Behavioral baseline and anomaly detection. AI is well suited to learning what normal looks like in a specific environment and flagging deviation from that baseline. That's harder than it sounds in practice because 'normal' in a federal cloud environment shifts constantly. AI models that can adapt their baseline dynamically catch the kind of slow-moving, low-and-slow adversary behavior that static rule sets miss entirely.

Contextual vulnerability evaluation at VDR scale. VDR requires evaluating every detected vulnerability against internet reachability, known exploitation status, exploit automation potential, and potential agency impact. In an environment with hundreds of findings per cycle, doing that contextual evaluation manually is not operationally realistic. AI models process the four-variable assessment for every finding, surface the high-risk combinations that require fast action, and let analysts focus on the decisions that require human judgment. What VDR requires analytically, AI makes executable at real-world volume.

Analyst augmentation for faster, better decisions. AI tools that provide analysts with contextual summaries, suggested playbook steps, and historical pattern matching reduce the cognitive load on the humans making the critical calls. They make experienced analysts faster and make less-experienced analysts more effective. That matters in a talent market where experienced SOC analysts are scarce and turnover is high.

The principle we operate by: agents observe and propose, humans approve. AI surfaces the finding, recommends the action, provides the context. The analyst decides. That's not a limitation of the technology. It's the right model for environments where a wrong call has mission consequences.

The organizations trying to use AI to eliminate analyst headcount will get faster automated responses to the threats AI already knows how to recognize. They'll be blind to the ones it doesn't. The organizations using AI to make their analysts better will get both speed and coverage. That's the only version of this that actually reduces risk.

The integration question nobody asks until it's too late

Here's what we've learned from doing this work across DoD, DHS, HHS, Treasury, and commercial environments for nearly two decades:

The hardest part of Defend isn't the technology. It's the integration.

A SOC that doesn't understand the architecture it's watching generates noise, not signal. A VDR operation that isn't connected to the engineering team that built the system misses the context that separates a finding from a critical finding. An MDR capability that's deployed on top of an environment it didn't help build lacks the baseline knowledge to detect meaningful deviation.

InfusionPoints operates differently because all four stages of the CTP engine share context. When our engineers build or migrate a system on XBU40, our operations team inherits knowledge about that environment. When Prove surfaces a VDR finding through Command Center and AuditShield, the team that responds understands the system well enough to evaluate exploitability accurately and prioritize correctly. When an incident occurs, the VNSOC360° engagement starts from a foundation of actual system knowledge, not a cold handoff.

That continuity of context is what makes the difference between security operations that generate PDFs and security operations that stop threats.

What good looks like

We've supported environments ranging from small federal contractors handling CUI for the first time to large cloud service providers maintaining FedRAMP High authorizations through multiple assessment cycles. The common thread in the programs that hold up isn't budget or tool selection. It's operating discipline.

Good looks like this:

Detection time measured in minutes, not months. Mean time to detect should be a tracked metric, reviewed regularly, with active work to reduce it. If you don't know your MTTD, you don't know if you're improving.

Response that starts from a playbook and a briefed team. Playbooks shouldn't be written during an incident. They should be tested, updated, and rehearsed. The team running response should have practiced the scenarios they're most likely to face.

Monitoring that covers the actual threat surface. Cloud workloads. Endpoints. Identity. Network egress. SaaS applications with access to sensitive data. Coverage gaps are where adversaries establish persistence, and coverage gaps are almost always where the last incident started.

VDR evidence that comes from persistent operations, not periodic assembly. If your VDR deliverables require a team to manually collect findings, evaluate context, and format records before each reporting cycle, you've built the old model with a new name. Under VDR, vulnerability records must be maintained continuously, evaluations must happen within days of detection, and evidence must be available for agency review at any time. Automation generates the records and evaluations. Your team interprets them, makes the contextual calls VDR requires, and acts.

Vulnerability management that reflects VDR, not just CVE scores. CISA BOD 26-04 and FedRAMP's VDR rules retired CVSS-only prioritization. Good vulnerability management now evaluates internet reachability, known exploitation status, exploit automation potential, and potential agency impact for every finding. The highest-risk combinations require remediation in days, not months. If your vulnerability management program isn't built around those four variables, it isn't built for the current requirement.

Leadership visibility into posture, not just findings. Executives don't need a list of CVEs. They need to understand trending posture, open risk, response time performance, and whether the current state of the environment matches the current state of the Security Decision Record. That picture should be available continuously, not reconstructed quarterly.

Why this matters differently for FedRAMP 20x, Rev5, and DoD/RMF

VDR and VER aren't a single compliance event with a single deadline. For FedRAMP 20x CSPs, VDR is the foundation the entire 20x model was built on, not a retrofit, and the rules became effective July 4, 2026 with no grace period. For Rev5 CSPs, VDR and VER are the exception to the January 2027 CR26 effective date, pulled forward to December 7, 2026 by CISA BOD 26-04, with certification revocation after March 7, 2027 for non-compliant offerings. The practical implication: building VDR compliance today is building toward 20x readiness simultaneously. The full path-by-path breakdown, including what each deadline means operationally for your authorization type, is in our dedicated VDR/VER post: https://infusionpoints.com/blogs/fedramp-vdr-ntc-0014-cisa-bod-26-04

DoD and RMF: FedRAMP is the floor, not the ceiling. For organizations pursuing or maintaining DoD IL4 or IL5 authorization, FedRAMP is the prerequisite, not the destination. FedRAMP Moderate (now Class C) feeds IL4. FedRAMP High (Class D) feeds IL5. Per the DoD Cloud Computing Security Requirements Guide (CC SRG) V1R6, there is no longer a path to IL5 using the FedRAMP Moderate baseline. DoD authorization layers additional requirements on top of FedRAMP, not instead of it. DoDI 8531.01 establishes DoD's vulnerability management program independently of FedRAMP's VDR rules, and DISA's ACAS scanning requirements add scan frequency and evidence format obligations beyond what FedRAMP requires. What CISA BOD 26-04 and FedRAMP's VDR framework require for federal civilian agency cloud is closely aligned with what DoD's RMF has required operationally for years. The shift in the civilian federal world is toward the posture DoD customers have expected all along: persistent detection, contextual evaluation, and response timelines measured in days for high-risk findings, not months.

The connection across all three tracks is direct. An organization that builds continuous vulnerability detection and response capability to meet FedRAMP VDR requirements is simultaneously building toward FedRAMP 20x readiness and meeting the operational posture DoD RMF assessors expect. These aren't separate compliance programs requiring separate investment. They're the same operating model, validated against three different frameworks with three different assessment approaches.

InfusionPoints serves customers across all three tracks from a single integrated platform. XBU40 provides the pre-authorized AWS GovCloud foundation for IL4 and IL5 workloads. VNSOC360° delivers the persistent detection and 24x7 response capability that both VDR and DoD RMF expect. Command Center and AuditShield generate the continuous, machine-readable evidence that 20x KSI validation and VER reporting require. The CTP engine doesn't rebuild for each framework. It runs continuously and produces the outputs each framework needs.

The bottom line

Compliance gets you to the starting line. Defend keeps you in the race.

The regulatory environment tightened significantly in June 2026. FedRAMP's CR26 Consolidated Rules, published June 24, established mandatory adoption of VDR and VER by December 7, 2026 for every FedRAMP-authorized CSP. That deadline was driven by CISA Binding Operational Directive 26-04, which fundamentally changed how vulnerability prioritization works across the federal government. After a grace period ending March 7, 2027, FedRAMP certification will be revoked for offerings not in compliance. The June 2026 FAR CUI proposed rule simultaneously extends 800-171 requirements to the broader federal contracting base.

These are not documentation challenges. They're operating model challenges. The organizations treating VDR adoption as a paperwork exercise, relabeling their existing POA&M spreadsheets and calling it done, will find themselves out of compliance and potentially out of the market. The ones that treat it as an opportunity to build the continuous, integrated detection and response capability the framework now requires will come out stronger.

We built the Continuous Trust Platform, with VNSOC360° as its Defend engine and VDR/VER delivery woven through Operate and Prove via ConMon-as-a-Service, because the market had no shortage of tools and a significant shortage of integrated operational capability. Nearly two decades of field experience across DoD, DHS, HHS, Treasury, and commercial environments taught us that the gap is almost never in the technology stack. It's in the people who watch the stack, understand what they're watching, and know what to do when it matters.

That's what Defend means to us. Not a product. Not a dashboard. An operating posture that's active every hour of every day, built on genuine knowledge of your environment, and accountable to the mission outcomes your customers depend on.

References

InfusionPoints VDR/VER deep-dive: https://infusionpoints.com/blogs/fedramp-vdr-ntc-0014-cisa-bod-26-04

FedRAMP Vulnerability Detection and Response rules: https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/

FedRAMP Consolidated Rules for 2026: https://fedramp.gov/2026

FedRAMP Notice 0014 (VDR/VER mandatory adoption): https://www.fedramp.gov/notices/0014/

FedRAMP Agency POA&M guidance under CR26: https://www.fedramp.gov/2026/agencies/use/ongoing/poams/

CISA BOD 26-04: https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk

CISA BOD 26-04 Implementation Guidance: https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk

DISA DoD Cloud Computing Security Requirements Guide (CC SRG): https://www.cyber.mil/dccs/dccs-documents/

DoD Instruction 8531.01, DoD Vulnerability Management: https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/853101p.pdf

DoD Risk Management Framework (RMF), DoDI 8510.01: https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/851001p.pdf

What comes next: inside the architecture

This post describes the operating model. The next six posts go inside it.

InfusionPoints built VNSOC360° and ConMon-as-a-Service on AWS-native services, deployed in the same regions and at the same authorization levels as our customers' environments. That architecture decision isn't incidental. It's what makes the operating posture described above possible at federal scale.

The AWS-Native Security Operations Series covers the full stack:

1. Why AWS-native is the only architecture that works for federal security operations

2. How we detect threats across your AWS environment using GuardDuty, Security Hub, Inspector, Macie, IAM Access Analyzer, and Detective

3. The log pipeline from CloudTrail and CloudWatch through Kinesis into OpenSearch and S3 that makes every incident auditable

4. How Config, conformance packs, and the integrated ConMon workflow replace periodic compliance with continuous compliance

5. Command Center, the platform that connects detection, compliance, remediation, and authorization into a single lifecycle view

6. How AWS Bedrock and AgentCore are augmenting our analysts and engineers without replacing the judgment calls that matter

If you want to understand the operating model, start here. If you want to see how it's built, the series is waiting.

Ready to talk about what continuous defense looks like for your environment? Contact InfusionPoints at info@InfusionPoints.com or 336-990-0252.