DoD STIG Explained: Categories, Workflow, and ATO Impact

DoD STIG compliance means configuring every system that touches the Department of Defense network according to the Security Technical Implementation Guides published by the Defense Information Systems Agency. DISA maintains roughly 400 of these guides, each tied to a specific product and version, and each translates broad federal security controls into the exact settings an administrator has to apply.¹² The requirements come from NIST Special Publication 800-53, filtered through a DoD baseline, and DISA is charged under DoDI 8510.01 with keeping the guides consistent with NIST SP 800-53 and CNSSI 1253.³

Who Has to Comply

Any system that connects to the DoD Information Network needs STIG compliance. DoDI 8510.01 states the scope plainly: the Risk Management Framework applies to all DoD systems and organizations regardless of acquisition pathway, along with partnered systems that have agreed to follow DoD standards.³

Private contractors are pulled in through DFARS clause 252.204-7012, which requires anyone handling covered defense information to implement the security controls in NIST SP 800-171 on the systems that store or process that information. The same clause imposes a 72-hour cyber incident reporting deadline and a 90-day media preservation requirement after a breach is discovered.⁴ The clause sits in every defense contract except those exclusively for commercial off-the-shelf items, and it flows down to subcontractors at every tier.⁵

Federal civilian agencies operate under FISMA rather than STIGs directly, but the underlying standards (NIST SP 800-53 and FIPS 200) closely parallel what STIGs enforce, and many civilian agencies adopt STIGs voluntarily as a proven hardening baseline.⁶

What the Severity Categories Mean

Every STIG finding carries one of three severity ratings, and the rating decides how much attention it gets and whether a system can be authorized to operate.

Category I is the most critical. A CAT I finding lets an attacker bypass primary security protections, gain immediate unauthorized access, or assume superuser privileges. A system with an open CAT I generally cannot receive an Authorization to Operate unless the system is mission-critical and no alternative exists.
Category II findings could lead to unauthorized access or activity if left alone. They can usually be mitigated and will not block an ATO on their own, but they widen the attack surface and demand prompt remediation.
Category III findings improve overall security posture but are not required for authorization. Across many systems they still create cumulative risk, so treating them as permanently optional is a mistake.

Auditors reviewing a system focus on CAT I first. A single unresolved CAT I can hold up an entire deployment, while a handful of documented CAT III findings on a plan of action typically will not.

The Compliance Workflow

STIG compliance is a repeating cycle: scan, document, remediate, re-scan. The administrative overhead is real, and underestimating it is one of the most common mistakes teams make when planning an authorization package.

Work starts with downloading the correct STIG for the exact product version in use from the DISA Cyber Exchange.¹ The SCAP Compliance Checker, developed by Naval Information Warfare Center Atlantic, then automates verification against the running system. SCC performs authenticated configuration scans using SCAP content and supports local and remote scanning of Windows, Linux, Solaris, and Cisco IOS devices through graphical and command-line interfaces.⁷ Not every requirement can be checked automatically. Rules that need human judgment or physical inspection still require manual review, so SCC output is a starting point rather than a finished assessment.

Findings get recorded in a checklist file created through STIG Viewer, which reads the XCCDF-formatted files DISA distributes and lets administrators mark each rule as Open (failed), Not a Finding (passed), or Not Applicable. STIG Viewer 3 moved the checklist format from XML .ckl files to JSON .cklb files, so teams carrying legacy checklists forward will need to convert or re-create them.⁸

For findings marked Open, the administrator applies the fix or documents why the fix cannot be applied and what compensating controls stand in for it. Teams managing large fleets often lean on DISA’s supplemental automation content in Ansible, Chef, and PowerShell DSC formats, which apply STIG configurations programmatically alongside updates to the STIGs themselves.⁹ The completed checklist becomes part of the system’s authorization package.

How This Feeds Your Authorization to Operate

STIG work exists to support the Risk Management Framework in DoDI 8510.01, which governs how every DoD system receives and keeps its Authorization to Operate. Any system with digital capabilities needs a valid ATO before beginning operations, and a system that never started the RMF process does not get a pass because it has been running for years without one.³

An Authorizing Official reviews the security authorization package, including STIG checklists, scan results, and any open Plans of Action and Milestones, and decides whether to grant or deny the ATO. The Authorizing Official can downgrade or revoke an ATO at any time if risk conditions warrant it.³ A system that loses authorization gets disconnected from the network, which for a deployed operational system can directly affect mission capability.

Plans of Action and Milestones

When a vulnerability cannot be fixed immediately because of operational constraints or technical limits, it goes into a Plan of Action and Milestones. A POA&M lists each non-compliant control, the remediation or mitigation tasks required, the resources needed, and specific milestones with completion dates.¹⁰ It is not a parking lot for things you plan to ignore. Component-level security officials monitor POA&M execution, and milestones that slip require documented justification.

Continuous Monitoring, Not a Three-Year Gate

The RMF replaced the old three-year certification cycle with continuous monitoring. Systems have to be watched on an ongoing basis: reassessing controls, documenting environmental changes, and conducting risk assessments.³ Assessment frequency tracks risk, with higher-risk controls reassessed more often than lower-risk ones.¹¹ STIG scans, then, are not an annual event. Configuration drift happens as patches land, software updates, and administrators make changes, and each change can introduce new findings.

CMMC for Defense Contractors

The Cybersecurity Maturity Model Certification program layers verification on top of the existing DFARS obligation. The final rule at 32 CFR Part 170 codifies CMMC, and Phase 1 implementation began after both that rule and the companion acquisition rule at 48 CFR Part 204 took effect.¹² Phase 1 runs from late 2025 through late 2026 and focuses on Level 1 and Level 2 self-assessments.¹³

Three levels sort contractors by how rigorously their cybersecurity is evaluated:

Level 1 (Foundational) requires the 15 basic safeguarding requirements from FAR 52.204-21. Contractors self-assess annually with senior official affirmation. POA&Ms are not permitted at this level, so every requirement has to be fully met.¹²
Level 2 (Advanced) requires all 110 security requirements from NIST SP 800-171 Rev. 2. Lower-risk programs may allow annual self-assessment, while prioritized acquisitions require certification by an accredited third-party assessment organization every three years. POA&Ms are allowed but must close within 180 days.¹⁴¹²
Level 3 (Expert) adds 24 requirements from NIST SP 800-172 on top of Level 2. Government assessors from the Defense Industrial Base Cybersecurity Assessment Center evaluate these organizations every three years.¹²

The consequence is direct: contracting officers will not award contracts or exercise options if the offeror does not hold the required CMMC status, and CMMC obligations flow down to subcontractors at every tier based on the sensitivity of information each subcontractor handles.¹² Full rollout across the defense industrial base is estimated at about seven years, but contractors that wait to start preparing will find themselves shut out of solicitations well before then.

Cloud Does Not Remove the Obligation

Moving DoD workloads to the cloud splits STIG responsibility rather than removing it. The cloud service provider handles physical security, the hypervisor, and underlying infrastructure. The mission owner still has to configure guest operating systems, applications, databases, and security groups according to the applicable STIGs.¹⁵

DoD cloud offerings need a Provisional Authorization built on FedRAMP with additional DoD controls layered on through what DISA calls FedRAMP+. That Provisional Authorization attaches to a specific cloud service offering, not the provider as a whole. Mission owners inside that offering still apply the relevant operating system, application, and network STIGs to their portion of the environment. Problems arise when mission owners assume the provider is handling something that actually falls on their side of the line.¹⁵

Where Teams Get Tripped Up

The most frequent failure after an initial scan is treating the checklist as a one-time exercise. A system that passed every STIG check at assessment can drift out of compliance within weeks as patches, users, and configurations change. Without regular re-scanning built into the operational rhythm, teams end up scrambling before audits.

The next mistake is downloading a STIG that does not match the exact product version in use. A Windows Server 2022 STIG applied to a 2019 installation will flag settings that do not exist and miss settings that do. DISA publishes version-specific guides for a reason, and using the wrong one produces both false positives and dangerous blind spots.

For contractors in 2026, the biggest risk is underestimating the CMMC timeline. The 110 controls at Level 2 reach into access control, incident response, media protection, system integrity, and roughly a dozen other security families. Organizations that have not started implementing NIST SP 800-171 should expect the work to take months rather than weeks, and the 180-day POA&M window at Level 2 does not reset if you miss it.

1
Cyber Exchange. STIGs Document Library
2
National Institute of Standards and Technology. Computer Security Resource Center Glossary – Security Technical Implementation Guide
3
U.S. Department of Defense. DoDI 8510.01 – Risk Management Framework for DoD Systems
4
Department of Defense. DFARS 252.204-7012 – Safeguarding Covered Defense Information and Cyber Incident Reporting
5
Department of Defense. Safeguarding Covered Defense Information – The Basics
6
Centers for Medicare and Medicaid Services. Federal Information Security Modernization Act (FISMA)
7
Naval Information Warfare Center Atlantic. Security Content Automation Protocol (SCAP) Compliance Checker
8
Cyber Exchange. SRG and STIG Tools
9
Cyber Exchange. Supplemental Automation Content
10
Center for Development of Security Excellence. Plan of Action and Milestones (POA&M) Job Aid
11
NIST Computer Security Resource Center. Continuous Monitoring in a Risk Management Framework
12
Federal Register. Cybersecurity Maturity Model Certification (CMMC) Program
13
Department of Defense. Cybersecurity Maturity Model Certification
14
Department of Defense. CMMC Alignment to NIST Standards
15
U.S. Department of Defense Chief Information Officer. Cloud Security Playbook Volume 1