Securing the Foundation: VMware Cloud Foundation 9.1 STIG Compliance

Introduction

Security compliance in modern infrastructure must evolve from a one-time exercise into an ongoing operational practice. For organizations in the U.S. Department of Defense (DoD), and the personnel who support them, that practice is anchored to a specific standard: the Security Technical Implementation Guide (STIG).

This post explores the definition of a STIG, its impact on the security posture of VMware Cloud Foundation (VCF), the evolution toward more approachable compliance workflows, and the resources available to begin implementation.

What Is a STIG?

A Security Technical Implementation Guide (STIG) is a configuration standard published by the Defense Information Systems Agency (DISA) that specifies how a given software product must be configured to meet DoD security requirements. STIGs define not just what needs to be configured, but how it needs to be configured, including the specific settings, values, and verification steps a system must meet in order to be considered acceptable for use in DoD environments.

STIGs are organized around a set of security controls derived from NIST SP 800-53 and the broader DoD security framework. Each individual requirement within a STIG is called a control (or a rule), and each control has a severity rating (Category I, II, or III, which correspond to high, medium, and low impact), a description of the security setting, the steps to verify compliance, and the steps to remediate a finding.

Who Are STIGs Designed For?

STIGs are primarily written for DoD and federal government system administrators, security engineers, and authorizing officials who need to operate systems within the DoD Information Network (DoDIN)[1]. However, the standards they encode are rigorous enough that many financial services organizations, healthcare systems, defense contractors, and security-conscious enterprises also adopt them as a baseline, even outside of a formal DoD accreditation process.

That said, STIGs are not one-size-fits-all. They are written to harden a system for the most sensitive and adversarial environments imaginable, and applying every control without evaluation could break functionality that your organization actually needs. Certain controls assume specific DoD infrastructure exists (e.g., a Public Key Infrastructure for smart card authentication) that may not be present in your environment. Before applying STIG content, every organization should evaluate each control against its operational requirements and document any exceptions using compensating controls or a formal acceptance of risk signed by an Authorizing Official.

STIG vs. STIG Readiness Guide: What’s the Difference?

This is one of the most common points of confusion, so it’s worth addressing directly.

A STIG is a finalized, DISA-approved document that has gone through a formal review and approval process. It is published on the DISA STIG repository[2] and carries an official DISA identifier.

DISA publishes Security Requirements Guides (SRGs), which define broad security requirements at the technology category level, covering classes of products like operating systems, application servers, web servers, and databases. These are the upstream source documents from which individual product STIGs are derived.

Broadcom uses the term STIG Readiness Guide (also abbreviated SRG[3]) to denote content produced in anticipation of a formal STIG. It maps the same DISA requirements to specific product configurations, but it has not yet gone through DISA’s formal approval process. The content is substantively identical in intent and rigor to what will eventually become the official STIG, but it carries a disclaimer[4] that it is not yet a final DISA publication.

The VCF 9.x content released here is currently in STIG Readiness Guide status. An official DISA-reviewed STIG for the VCF 9.1 project is in progress. When it is published on public.cyber.mil, the automation content will be updated to align with the finalized control identifiers and severity ratings.

VCF’s Multi-Component Architecture Demands a Multi-STIG Approach

This is where VCF compliance gets interesting, as VCF is a unified platform that integrates technologies such as VMware vCenter, ESX, NSX, SDDC Manager, VCF Automation, VCF Operations as integrated components, and other new components, in addition to the underlying Photon OS that powers the appliances. Each of those components has several DISA Security Requirements Guides that may apply to it (OS, Web Server, Database, etc.), meaning a single VCF deployment may need to demonstrate compliance against a dozen or more guides simultaneously.

What this means practically is that there is no single “VCF STIG.” There is instead a collection of guidance documents, one per component or service. For the VCF 9.1 Y26M05 release, the readiness guide covers:

Product-Level Guidance (Application)

• VCF Application (platform-wide controls)
• VCF vSphere (ESX hosts, vCenter, and Virtual Machines)
• VCF NSX Manager and Routing
• VCF Automation
• VCF Operations
• VCF Operations for Networks
• VCF Operations HCX
• VCF SDDC Manager

Appliance OS and Service Guidance

• Photon OS 5.0 (used across all VCF appliances)
• vCenter Server Appliance (Envoy, PostgreSQL, VAMI services)
• SDDC Manager Appliance (NGINX, PostgreSQL services)
• Operations Appliance (Apache HTTP, PostgreSQL services)
• Operations for Networks Appliance (NGINX platform service)
• Operations HCX Appliance (Apache HTTP service)

That’s more than 20 distinct guidance areas covering over 500 individual controls across numerous audit profiles, all in a single coordinated release.

The reason the mapping is not one-to-one between DISA SRGs and VCF components is that DISA issues SRGs at the technology category level (application servers, operating systems, network devices, web servers, databases), while VCF is an integrated platform where those categories manifest across many individual services. A vCenter appliance, for example, not only runs Photon OS, but also runs web, database, reverse proxy, and management API services, each subject to its own SRG-derived controls.

Making Compliance Sustainable: Automation at Every Stage

Reviewing and remediating hundreds of STIG controls by hand is operationally unsustainable. At the scale of a full VCF deployment, manual application introduces higher risks of error, inconsistent results across environments, and cannot keep pace with the cadence of platform updates and new STIG releases. Automation is not simply a convenience; it is necessary for maintaining a defensible security posture over time.

The VCF 9.1 content is built around three automated workflows: scanning, remediation, and reporting.

Auditing with InSpec

Auditing is performed using MITRE’s InSpec (optionally Cinc Auditor, the open-source distribution used for licensing compliance).

Rather than publishing standalone profiles for each VCF component and leaving you to wire them together, the content is structured as a hierarchical baseline. Every profile accepts structured inputs that let you adapt controls to your environment without modifying any automation code. For example, approved NTP servers, authorized DNS resolvers, acceptable TLS cipher suites, and authorized users and groups are all configurable via an inputs file you manage alongside the documentation for your environment. A waiver mechanism lets you record accepted risks or not-applicable controls in a structured, auditable way.

Remediation with Ansible and PowerCLI

For findings that need to be corrected, there are two remediation paths:

• Ansible playbooks for appliance-level hardening, which include OS settings, service configurations, and file permissions.
• VCF.PowerCLI scripts for application-level settings that require the vSphere or VCF API.

Starting with the VCF 9.0 release, all Ansible roles required for STIG remediation across the full platform are consolidated into a single playbook, so remediation can target the entire environment simultaneously or address individual components (VMware vCenter, SDDC Manager, VCF Operations, etc.).

Both paths are designed to be run in sequence with an InSpec audit: scan first to establish a baseline, remediate findings, then scan again to verify. This scan-remediate-verify loop is the operational rhythm of continuous compliance.

Reporting with SAF CLI

Raw InSpec output is JSON. To make that output useful in accreditation workflows, the MITRE SAF CLI (Security Automation Framework CLI) converts scan results into STIG Checklist (CKL) files compatible with the DISA STIG Viewer. The checklist file becomes the evidence that auditors and Authorizing Officials[5] require. When regulators or customers ask how your infrastructure is hardened, a STIG-compliant environment backed by timestamped, structured scan reports is a credible, documented answer.

Known Considerations and Limitations

Honest compliance guidance requires acknowledging that applying STIG controls is not without operational impact. 

Functional trade-offs are real. Some controls, particularly around authentication, SSH access, and service availability, will affect how your operations team interacts with your infrastructure. For example, enabling smart card authentication for vCenter is a CAT I requirement that assumes a DoD PKI infrastructure. Enforcing it in an environment without that infrastructure will lock users out. Controls should always be validated in a representative non-production environment before applying them broadly.

Not every control is automatable, so a subset of controls will require manual verification. Physical access controls, organizational policy reviews, or configurations that are only accessible through interfaces that do not expose a programmatic API will appear as skipped in InSpec results and require manual attestation.

VCF version compatibility is strict. The Y26M05 content is validated for VCF 9.1.0.0 only. Applying it to a different version is not supported. Refer to the compatibility matrix in the repository’s README file.

What’s Next

As DISA progresses through the formal review and approval process for VCF 9.1, the GitHub repository content will be updated to align with any changes to control identifiers or severity ratings in the final STIG. Watch the individual CHANGELOG.md files within each content version folder for updates.

For questions, issues, or community-contributed improvements, the GitHub Issues tracker is the right place to start.

Compliance is an ongoing journey rather than a destination, and the VCF STIG Readiness Guide for 9.1 provides the necessary framework to navigate it. While the responsibility for thoughtful implementation within your specific environment remains with your team, the foundational tooling and guidance are now available to support your efforts.

Reach out to your VCF Technical Adoption Manager (TAM) for more information on STIG compliance, or talk to your Account Director about how you can engage our VCF Professional Services team to enhance security through STIG hardening.