What Is Continuous Monitoring in Federal Cybersecurity?

Federal systems do not hold still between assessment cycles. Configurations drift. New assets appear. Privileges get granted and quietly forgotten. Patches get applied to some systems and missed on others. Threat actors are not waiting for the next annual review before looking for gaps.

That operational reality is what continuous monitoring exists to address. Not as a compliance checkbox, but as the mechanism that keeps a program’s security picture current between formal assessment events. The Authorization to Operate a system received is based on its posture at a point in time. Everything that happens after that date is what ConMon is supposed to capture.

The problem is that most federal programs know this in principle and struggle with it in practice. The gap between what continuous monitoring is supposed to look like and what it actually looks like inside resource-constrained federal environments is significant. Understanding that gap, and being honest about what drives it, is the starting point for building something that actually works.

This article covers what continuous monitoring means in operational federal terms, how it fits within the RMF, where programs consistently fall short, and what a functional program looks like on the ground for ISSOs, ISSMs, and the teams supporting them.

What Continuous Monitoring Actually Covers

The formal definition is straightforward: continuous monitoring is the ongoing process of collecting, analyzing, and reporting security-relevant information about a system’s risk posture over time. The goal is to maintain situational awareness between formal assessment events so that mission owners and authorizing officials can make risk decisions based on current data rather than stale snapshots.

The distinction between point-in-time compliance and ongoing visibility matters here. A traditional assessment answers: were controls implemented correctly when we looked? Continuous monitoring answers a different question: what is the security posture of this system right now, and what has changed since the last formal review?

NIST defines continuous monitoring within the broader Information Security Continuous Monitoring framework documented in SP 800-137. The scope is intentionally broad, spanning organizational tiers, individual systems, and the data streams connecting them. In practice, a federal ConMon program includes:

• Asset visibility — knowing what hardware, software, and services actually exist on the system, including assets that postdate the original authorization package
• Vulnerability management — identifying and tracking known vulnerabilities across the asset inventory with a clear picture of patch currency and remediation timelines
• Configuration monitoring — detecting deviations from approved baselines, STIG requirements, and organizational configuration standards
• Log collection and analysis — gathering telemetry that supports detection of anomalous activity, unauthorized changes, and potential security events
• Change tracking — capturing changes to the environment that affect security controls or risk posture, and assessing their impact
• Reporting — synthesizing findings into risk-informed status that mission owners and authorizing officials can actually use to make decisions

That last point deserves emphasis. ConMon is not a data collection exercise. It is a risk communication exercise. The output that matters is not the finding count or the scan report. It is whether decision-makers have a current, accurate picture of what is happening on the systems under their authority.

How ConMon Fits Within RMF and Ongoing Authorization

In the Risk Management Framework, continuous monitoring is Step 6 and it is not optional. After a system is authorized at Step 5, the organization is expected to continue monitoring security controls, reporting on security status, and updating the authorization package as the environment changes. For DoD programs under DoDI 8510.01, additional specificity applies around eMASS documentation, STIG compliance monitoring, and defined reporting cadences, but the underlying logic is the same across both civilian FISMA environments and DoD RMF programs.

What RMF Step 6 requires in practical terms: a defined monitoring strategy that specifies what will be monitored, at what frequency, and by whom; ongoing monitoring of selected security controls; a process for responding to findings, updating POA&Ms, and escalating when warranted; security status reporting to authorizing officials; and updates to authorization documentation when the environment changes materially.

The Ongoing Authorization Model

The concept of ongoing authorization flows directly from this. Historically, an Authorization to Operate was a periodic event: get an ATO, operate for three years, go through the full process again. The ongoing authorization model moves away from fixed reauthorization cycles toward continuous, risk-informed decisions. If an authorizing official has reliable, current information about a system’s security posture, authorization decisions can be made based on that rather than waiting for a scheduled event.

That model only works if ConMon is generating reliable, current data. An ISSO submitting a monthly status report built from a scan run three weeks ago is not providing current information. They are providing historical data labeled as current, and the AO may not know the difference. Authorization packages that are accurate at approval but never meaningfully updated create a growing mismatch between documented posture and operational reality. Continuous monitoring requirements exist precisely to prevent that gap from widening to the point where the package becomes fiction.

The NIST 800-53 control families most directly tied to ConMon include CA (Assessment, Authorization, and Monitoring), SI (System and Information Integrity), AU (Audit and Accountability), and CM (Configuration Management). An effective ConMon program is not running parallel to NIST 800-53 compliance. It is how organizations demonstrate those controls are actually working and remain effective over time.

Why Vulnerability Scanning Is Not ConMon

This is the most common misconception in federal ConMon programs and worth addressing directly. Running a vulnerability scanner is not the same as doing continuous monitoring. Vulnerability scanning is one input into a ConMon program, and an important one. But it does not give you the full picture, and programs that treat it as the entire program have significant visibility gaps they may not know exist.

Here is what a vulnerability scan typically does not tell you.

Asset inventory accuracy. A scan covers the scope you give it. If the asset inventory is incomplete, the scan reports clean results on what it knows about. The blind spots do not appear in the report. They remain invisible until something goes wrong.

Configuration and policy compliance. A vulnerability scanner identifies missing patches and known software vulnerabilities. It does not tell you whether GPO settings match the approved STIG baseline, whether a privileged account was added outside the change management process, or whether a prohibited service was enabled last week.

Behavioral telemetry and log data. What is happening on systems between scans is not visible through scanning. Authentication patterns, privilege use, data access activity, anomalous network behavior — that visibility comes from log collection and analysis, not scan reports.

User and account activity. Whether accounts are being used appropriately, whether privileged access is limited to authorized personnel, whether dormant accounts should have been disabled — that requires audit log review and access control monitoring, not scanner output.

Change awareness. When something changes in the environment, a scan may or may not catch it depending on timing and scope. A change management process that is not integrated with security review creates gaps that scanning alone will not surface.

What Federal Programs Consistently Underestimate

Most federal cybersecurity practitioners understand continuous monitoring conceptually. The harder part is sustaining it in practice, particularly in environments where workload and headcount do not align. A few patterns show up consistently across federal programs that are struggling with ConMon.

The multi-system ISSO problem

When one ISSO is responsible for three, four, or five systems simultaneously, the depth of continuous monitoring for any one of those systems is necessarily limited. ConMon is an ongoing discipline. It does not compress well into the margins of an already full workload. The result is often a program that meets the minimum reporting bar but does not generate the kind of current, actionable visibility that ongoing authorization is supposed to rely on. This is not a personnel failure. It is a structural problem that requires deliberate process design to work around.

Manual reporting that consumes analysis time

Monthly ConMon reporting in many federal programs is still heavily manual: pulling scan exports, reconciling findings across sources, updating spreadsheets, drafting status summaries. That process can consume most of the time available for ConMon activities, leaving little capacity for what the process is actually supposed to produce. What changed? What is trending in the wrong direction? What does leadership need to make a decision? When data collection consumes the time meant for analysis, the analysis does not happen.

Incomplete asset visibility as a hidden baseline problem

If the asset inventory is wrong, every ConMon output built on top of it is incomplete. Cloud instances that spun up informally, contractor-managed assets outside the accreditation boundary, software installed outside the configuration management process — these gaps mean the ConMon program is only monitoring a subset of what it believes it is monitoring. Asset inventory accuracy is not a one-time effort at authorization. It requires an ongoing process for capturing authorized changes and detecting unauthorized additions.

Configuration drift that accumulates quietly

Production systems do not stay in their authorized configuration indefinitely. Patches get applied. Services get added. Settings get changed under operational pressure, sometimes without documentation. Without a process for detecting and assessing drift, the delta between what the authorization package describes and what is actually running grows over time, often invisibly, until it surfaces during a formal assessment at the worst possible moment.

Reporting that looks good without informing decisions

Mission owners and authorizing officials do not need a 200-item finding list. They need to understand: what is the current risk picture, what has changed since last month, and is there anything that warrants a decision? ConMon programs that generate data without synthesizing it into usable risk information leave leadership making decisions without the context they actually need. A report that looks clean is not always a report that is useful.

What a Functional ConMon Program Looks Like

A well-functioning ConMon program does not have to be complex. But it needs to cover the right ground consistently, and the specifics vary based on system type, mission context, classification level, and available resources. Effective programs share certain foundational elements regardless of size or scope.

Accurate and maintained asset inventory. ConMon starts with knowing what is being monitored. Hardware, software, network services, cloud resources, and authorized connections need to be documented and kept current through a process that captures authorized changes and detects unauthorized additions. An inventory accurate at authorization time but never updated since is not a working foundation.

Vulnerability visibility with remediation tracking. Regular scanning of known assets, with results tracked over time and compared against prior cycles. What is the current finding count by severity? What has changed since last month? What is patch latency for critical findings? Vulnerability data should drive prioritized remediation, not just populate a spreadsheet that no one acts on.

Configuration monitoring against approved baselines. Systems should be assessed against approved configuration documentation, including STIG checklists and organizational security policies. Deviations need to be identified, tracked, and either remediated or formally accepted as residual risk. For programs managing STIG automation workflows, integrating configuration scan results into the ConMon cycle is where recurring compliance monitoring becomes operationally sustainable.

Meaningful log collection and review. Logging without review is not ConMon. Logs need to be collected, retained, and reviewed in a way that provides useful signal: what accounts are active, are privileged activities being logged, are there anomalies warranting investigation. This does not require a full-time analyst for every small system. It does require a defined process and someone responsible for running it.

Change tracking and impact assessment. When changes happen, and they always do, the ConMon program should capture what changed, assess whether it affects security controls, and update relevant documentation. A change management process not integrated with security review creates exactly the kind of quiet drift that surfaces as a surprise during assessments.

Repeatable processes with documented responsibilities. ConMon activities should be documented in a monitoring strategy that defines what is being monitored, at what frequency, who is responsible, and how findings get reported and dispositioned. When personnel turn over, the program should not depend on institutional knowledge that walks out the door with them.

Risk-informed reporting. The output of ConMon should tell decision-makers what they need to know: current risk posture, what changed since last month, and whether anything warrants a decision. A status report that looks clean by design, without reflecting actual posture, is worse than a report that surfaces uncomfortable findings. The AO needs current information, not good-looking information.

Common Mistakes

Recommended Federal Approach