DISA STIG compliance means configuring your technology to match the Security Technical Implementation Guides published by the Defense Information Systems Agency, the DoD body that writes and maintains those product-specific security baselines. If your system connects to a DoD network or handles defense-related data, following the applicable STIGs isn’t optional. DoD Instruction 8500.01 requires all DoD information technology to comply with applicable STIGs, with any exceptions documented and approved by an authorizing official.1Department of Defense. DoD Instruction 8500.01 – Cybersecurity
What a STIG Is
A STIG is a product-specific document that tells you exactly which settings to change, which features to disable, and which configurations to enforce before a product can be used in a DoD environment. The guides replace factory defaults, which generally favor ease of use, with hardened configurations covering passwords, file permissions, encryption protocols, logging, and access controls. Each individual requirement is called a rule or check, and every rule maps back to a security control from NIST Special Publication 800-53.2Department of Defense. DoD Instruction 8510.01 – Risk Management Framework for DoD Systems
STIGs sit at the most granular level of a layered guidance structure. Above them are Security Requirements Guides, which group requirements by technology category, such as operating systems or web servers, without targeting a specific product. An SRG says what needs to happen. A STIG says exactly how to make it happen on a named product like Red Hat Enterprise Linux 9 or Windows Server 2022. DISA publishes both through its Cyber Exchange library, which is freely accessible and refreshed on a quarterly cycle.3Cyber Exchange. SRG and STIG Library Compilations
The library is intentionally broad. It covers operating systems, network gear like routers and firewalls, cloud and virtualization platforms, databases, web and application servers, mobile devices, and even browsers, PDF readers, and office suites. Any component that touches a DoD network is treated as a potential entry point.3Cyber Exchange. SRG and STIG Library Compilations
Who Must Follow STIGs
DoD Instruction 8500.01 applies STIG requirements to all DoD information technology, which covers every military branch, defense agency, and internal DoD organization.1Department of Defense. DoD Instruction 8500.01 – Cybersecurity Federal civilian agencies frequently adopt STIG baselines as well, particularly when their systems exchange data with DoD networks or process sensitive information subject to the Federal Information Security Modernization Act.
Private-sector contractors are pulled in through a different mechanism. Defense Federal Acquisition Regulation Supplement clause 252.204-7012 requires contractors to provide adequate security for covered defense information on their systems. At a minimum, contractors must implement the controls in NIST SP 800-171, and many DoD contracts go further by explicitly requiring STIG compliance for systems that connect to DoD networks.4Department of Defense. Guidance for Selected Elements of DFARS Clause 252.204-7012 The Cybersecurity Maturity Model Certification program adds another layer, requiring third-party assessments of cybersecurity practices before contract award, but CMMC focuses on organizational maturity rather than individual system configurations, so it complements STIG compliance rather than replacing it.
Severity Categories and Why They Matter
Every finding in a STIG is assigned one of three severity categories, and those categories drive how auditors and authorizing officials evaluate your risk posture.
- CAT I (High). If exploited, the vulnerability could directly cause a data breach or total loss of system availability. Examples include unencrypted classified data transmissions or disabled authentication controls. These get fixed first, no exceptions.
- CAT II (Medium). The finding has real potential to cause a security incident but won’t immediately destroy system integrity the way a CAT I will. Left unaddressed, CAT II findings tend to escalate. Most STIG rules fall here.
- CAT III (Low). These weaken your security posture without directly enabling an attack, such as a missing audit log setting or a slightly permissive file permission. They still need remediation, but they typically won’t hold up an authorization decision on their own.
In practice, an authorizing official reviewing your system will scrutinize open CAT I findings far more aggressively than CAT IIIs. A handful of documented and accepted CAT III findings is normal. Open CAT I findings with no mitigation plan is a fast way to lose your network connection.
What Happens If You Don’t Comply
For a DoD system, the most immediate consequence is losing authorization to operate. Without a valid ATO, the system gets disconnected from the network. For a weapons system, a command-and-control platform, or a logistics application, that’s an operational crisis rather than a theoretical risk.
Contractors face a different but equally serious set of consequences. A 2022 DoD memorandum identified specific remedies for DFARS cybersecurity noncompliance, including withholding progress payments, declining to exercise remaining contract options, and terminating contracts in part or in full. Beyond contract-level penalties, the Department of Justice has pursued cybersecurity cases under the False Claims Act, which applies when a contractor certifies compliance with contract requirements it hasn’t actually met. At least one such settlement has reached $8.4 million. A False Claims Act investigation can also lead to suspension or debarment from all future government contracting.
How Compliance Actually Gets Done
The work follows a predictable pattern, though the scale varies with how many systems you manage. Start by building a complete inventory of every hardware and software asset within your assessment boundary. Match each asset to its applicable STIG version on Cyber Exchange. Version mismatches are a common early mistake. Running a Windows Server 2019 STIG against a Server 2022 installation will produce inaccurate results and waste time.
DISA provides specific tools and expects results in specific formats. STIG Viewer is the standard application for opening, reviewing, and managing STIG checklists. It saves your work as .ckl files, XML-based checklists that record the compliance status, comments, and finding details for every rule in the STIG, tied to target data like IP addresses, hostnames, and MAC addresses.5Defense Information Systems Agency. STIG Viewer 3.x User Guide6NIWC Atlantic. Security Content Automation Protocol (SCAP) Compliance Checker7Computer Security Resource Center. Security Content Automation Protocol Not every STIG has a SCAP benchmark, so some checks still require manual verification.
Remediation absorbs most of the time. Applying STIG settings means modifying registries, adjusting group policies, changing application configurations, and sometimes removing software or features entirely. Test in a non-production environment first. Hardened systems occasionally break applications that depend on permissive defaults, and discovering that in production is not a conversation anyone wants to have.
After remediation, rescan and update each finding’s status in the .ckl file. For findings you genuinely cannot remediate, perhaps because the fix would break a mission-critical application, document them in a Plan of Action and Milestones with a justification, a risk assessment, and a target resolution date. The POA&M becomes part of your authorization package.
Where STIGs Fit in the Risk Management Framework
STIG compliance is one component of the DoD’s broader Risk Management Framework, established by DoD Instruction 8510.01, which governs how every DoD system gets authorized to operate.2Department of Defense. DoD Instruction 8510.01 – Risk Management Framework for DoD Systems STIG work plugs into the implement and assess phases. You implement the required configurations, then assess whether they’re working. Your scan results and completed checklists feed into the security assessment report the authorizing official reviews before granting an ATO. The official weighs the residual risk from any open findings against the operational need for the system, then either grants the ATO, issues an interim authorization with conditions, or denies it.
Compliance isn’t a one-time project. DISA publishes updated and new STIGs at the end of January, April, July, and October, and each release can introduce new rules, modify existing ones, or retire outdated checks.8Cyber Exchange. Quarterly Release Schedule and Summary If you validated your systems against a Q1 release and DISA introduces new CAT I rules in Q2, your systems are now measured against the updated requirements. An ATO stays valid only as long as the system stays within its approved risk posture, so drift from the STIG baseline without documentation and approval is one of the fastest ways to trigger a reassessment or lose authorization entirely.