Continuous Authorisation and Ongoing Authorisation Guide: Moving Beyond Three-Year ATOs

A point-in-time authorisation to operate (ATO) describes a system as it was on the day of assessment, while software factories now change production many times a day. Ongoing authorisation in the NIST Risk Management Framework, the US Department of Defense continuous ATO (cATO) and FedRAMP's move to continuous, automated validation all try to close that gap by basing the risk decision on live monitoring data instead of a fixed reauthorisation cycle. This guide explains how the three models differ, what the DoD cATO memorandum and evaluation criteria actually require, what evidence and dashboards an authorising official needs, how to phase the transition and how authorisation is lost. It is for authorising officials and their staff, ISSMs and ISSOs, platform and DevSecOps leads, and cloud providers selling to US government. For building the monitoring programme itself see the NIST SP 800-137 Information Security Continuous Monitoring Guide; this page is about the authorisation decision that sits on top of it.

Key takeaways

• Continuous authorisation changes reauthorisation, not the ATO. The DoD cATO memorandum of February 2022 states that cATO does not change the underlying ATO; it changes the requirements for reauthorising it, and DoD CISO approved cATOs do not have an expiration date.
• DoD sets three competencies. The authorising official must demonstrate ongoing visibility of key cybersecurity activities inside the boundary, the ability to conduct active cyber defence in real time, and adoption of an approved DevSecOps reference design.
• NIST frames it as ongoing authorisation. SP 800-37 Rev. 2 asks organisations to make the transition to ongoing authorisation a priority, supported by continuous monitoring under SP 800-137; the 2014 NIST white paper on ongoing authorisation was withdrawn in 2019 and folded into SP 800-37 Rev. 2.
• FedRAMP is moving to automated validation. FedRAMP 20x replaces static yearly manual assessment with Key Security Indicators that show posture in near real time; FedRAMP states it will stop accepting new Rev5 certifications on 11 June 2027.
• Identity drives much of the evidence. Pipeline credentials, cloud entitlements (CIEM in the DoD criteria), separation of duties and onboarding and offboarding are all explicit evaluation points.

Three models compared

Choosing a model: a federal civilian agency uses RMF ongoing authorisation and decides its own triggers. A DoD programme with a software factory pursues cATO through the DoD CISO. A cloud provider follows FedRAMP, and should plan now for the 20x transition paths FedRAMP says it will publish for existing Rev5 offerings. Organisations outside government can borrow the same pattern for internal risk acceptance, without the formal approval chain.

What the DoD cATO memorandum requires

The memorandum, signed by the DoD Senior Information Security Officer, describes cATO as keeping systems authorised based on real-time risk posture supported by continuous monitoring, instead of periodic reauthorisation.

The three competencies

• Ongoing visibility: security controls feed a system-level dashboard giving the authorising official a real-time view, under the RMF continuous monitoring (CONMON) strategy that every system already needs.
• Active cyber defence: the ability to respond to cyber threats in real time, with the authorising official in constant communication with cyber operations components.
• Approved DevSecOps reference design: the system must adopt the DoD Enterprise DevSecOps Strategy and align with an approved reference design; a "Pathway to a Reference Design" exists for new architectures.

Evaluation criteria

The DevSecOps cATO Evaluation Criteria (the published file is marked draft version 19, dated December 2023 in its filename) guide DoD CISO review of software factories and DevSecOps platforms. Check for a newer version before relying on detail.

The criteria accept SPDX, SWID or CycloneDX for SBOMs without mandating one. See the SBOM Guide and the DevSecOps Guide.

Ongoing authorisation in the NIST RMF

In SP 800-37 Rev. 2 the Monitor step covers ongoing assessment of control effectiveness, documenting changes to the system and environment, risk assessments and impact analyses, and reporting security and privacy posture. The publication cites SP 800-137 for continuous monitoring supporting ongoing authorisation. The Monitor step tasks run from M-1 System and Environment Changes through M-2 Ongoing Assessments, M-3 Ongoing Risk Response, M-4 Authorization Package Updates, M-5 Security and Privacy Reporting and M-6 Ongoing Authorization to M-7 System Disposal.

• Time-driven reviews: the authorising official reviews posture on a schedule set in the monitoring strategy (for example monthly or quarterly), using current data rather than a new full assessment.
• Event-driven reviews: defined triggers prompt a fresh risk decision: a significant change, a new critical vulnerability, a failed control, an incident or a change in threat.
• Authorisation package as living data: the system security plan, assessment report and POA&M are updated continuously (Task M-4) so the package always reflects the current system.
• Common controls: inherited controls from a common control provider need their own ongoing authorisation; a system cannot be more current than the controls it inherits.

For the full RMF see the NIST Risk Management Framework (SP 800-37) Guide.

FedRAMP: from ConMon to 20x

Under FedRAMP Rev5, providers submit continuous monitoring deliverables (vulnerability scan results, POA&M and inventory updates), seek approval for significant changes and undergo an annual assessment that includes a penetration test at least every 12 months, per the FedRAMP Penetration Test Guidance. FedRAMP 20x shifts the emphasis to evidence that security decisions work, using Key Security Indicators (KSIs) validated automatically and trended over time. FedRAMP reports these phases on its 20x page:

Dates are as published by FedRAMP at the time of checking and may move. See the FedRAMP Guide for classes and routes.

Where identity fits

In a continuously authorised system, the identities that build and deploy software can change production without a human review of each change. That makes them central to the risk decision.

• Pipeline identities: CI runners, deployment service accounts and cloud roles used by the software factory need least privilege, short-lived credentials and separation between build and deploy. See the CI/CD Pipeline Identity Security Guide.
• Entitlement monitoring: the DoD criteria name CIEM under cloud-native protections. Over-scoped cloud roles should appear on the authorising official's dashboard as a posture metric, not only in an annual review. See the Cloud PAM and CIEM Guide.
• Separation of duties: the criteria require it to be verified. A single identity that can merge code, approve and deploy defeats the control gates that justify cATO.
• Onboarding and offboarding: include non-human identities. A departed engineer's personal access token or an abandoned integration key is an open path into a pipeline that deploys without further approval. See the NHI Offboarding and Decommissioning Guide.
• Logging: machine identity activity must be in the audit logs the criteria require to be collected, analysed and alerted on.

Implementation: a phased transition

1. Baseline the current ATO. Confirm the system has a valid ATO, a current system security plan and a CONMON strategy covering all controls. cATO and ongoing authorisation build on this; they do not replace it.
2. Define risk tolerance and triggers. Agree with the authorising official which metrics, thresholds and events require a fresh risk decision, and write them into the risk management and monitoring strategies.
3. Automate evidence for high-value controls first. Vulnerability management, configuration baselines, account management including machine accounts, and audit logging usually give the most signal. Map each automated check to its SP 800-53 control.
4. Build the authorising official dashboard. Show posture against tolerance, open POA&Ms by age, pipeline gate failures and trend lines. Test it with the authorising official before the request.
5. Prove active defence. Establish the CSSP relationship and SLA, run the third-party penetration test and at least one red or purple team exercise, and record lessons learned.
6. Align the pipeline. Adopt an approved reference design, document control gates and guardrails, produce SBOMs and move configuration to code.
7. Pilot and request. Run in "shadow" mode for a period, producing the dashboard and trigger decisions while the traditional ATO remains authoritative, then submit the request with artefacts.
8. Operate and review. Hold scheduled posture reviews, act on triggers and keep the package current.

Rollback: because a system can lose cATO without losing its ATO, plan the fallback in advance: what reverts to manual change approval, who can pause the pipeline and how reauthorisation would proceed.

Small versus large programmes: a single small system may get more from a clear event-driven reauthorisation process than from full cATO tooling. Enterprise software factories serving many mission systems get the most value, because one well-monitored platform supports many deployments.

Detection and measurement

• Evidence latency: time between a control state change and its appearance on the dashboard; target minutes to hours, not weeks.
• Automated control coverage: percentage of applicable SP 800-53 controls with automated or near-real-time evidence.
• Remediation within tolerance: share of vulnerabilities and POA&M items closed within the defined timelines.
• Gate effectiveness: number of builds blocked by control gates and the proportion later confirmed as true issues.
• Machine identity hygiene: count of pipeline and cloud identities with standing high privilege or credentials older than policy.
• Trigger response time: time from a defined trigger event to a documented authorising official decision.

Framework mapping

This mapping is NHI Mgmt Group's own indicative mapping of cATO activities to control IDs. For contractors handling CUI, SP 800-171 Rev. 3 requirement 03.12.03 Continuous Monitoring is the equivalent requirement.

Common failure patterns

• Dashboards without decisions: data flows to a dashboard nobody with authority reviews, so the "ongoing" authorisation is a three-year ATO with better charts.
• Undefined triggers: no written thresholds for when posture becomes unacceptable, so revocation never happens until an incident forces it.
• Pipeline as the blind spot: production is monitored but the software factory's own identities, secrets and runners are not, although they can change production directly.
• SBOMs produced but not used: SBOMs are archived but there is no process to match new CVEs against them, which the DoD criteria explicitly ask for.
• Inherited controls out of date: the system is continuously monitored but relies on a common control provider still on an annual cycle.
• Penetration test treated as one-off: the 90-day initial test is done, the annual repeat and exercise programme are not.

Practitioner checklist

• Confirm a valid ATO and a CONMON strategy covering all controls before starting.
• Write risk tolerances, metrics and event triggers into the risk management strategy.
• Automate evidence for vulnerability, configuration, account and logging controls first.
• Give the authorising official a tested, near-real-time dashboard.
• Put pipeline and cloud identities, their privileges and their credential age on that dashboard.
• Establish CSSP coverage and schedule third-party penetration tests and team exercises.
• Generate SBOMs and connect them to vulnerability intake.
• Document the fallback if cATO is revoked.
• For FedRAMP offerings, track the 20x transition paths and KSI requirements.

Standards and references

• US DoD CIO: Continuous Authorization to Operate (cATO) memorandum
• US DoD CIO: DevSecOps Continuous Authority to Operate Evaluation Criteria
• NIST: SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations
• NIST: SP 800-137, Information Security Continuous Monitoring
• NIST: CSWP 3, Supplemental Guidance on Ongoing Authorization (withdrawn)
• FedRAMP: FedRAMP 20x
• FedRAMP: Penetration Test Guidance
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls

Related NHI Mgmt Group resources: NIST SP 800-137 Information Security Continuous Monitoring Guide · Audit Evidence and Continuous Controls Monitoring Guide · FedRAMP Guide · NIST Risk Management Framework (SP 800-37) Guide · CI/CD Pipeline Identity Security Guide