Red Hat Becomes CRA Steward for Ansible: What Enterprise Users Must Do Before September 2026

On April 21, 2026, Red Hat announced on the Ansible Community Forum that it will serve as the Open Source Software Steward for the Ansible project under the EU Cyber Resilience Act (CRA). This is a significant development — and one that every enterprise using Ansible in production needs to understand, because what the Steward role covers and what it doesn't are two very different things.

What Just Happened

The Cyber Resilience Act (Regulation EU 2024/2847) introduces mandatory cybersecurity requirements for "products with digital elements" — essentially, any software or hardware placed on the EU market. Open source software occupies a special position in this regulation: the CRA recognises that volunteer-driven FOSS communities cannot bear the same compliance burden as commercial manufacturers.

To bridge this gap, the CRA created a new legal role: the Open Source Software Steward. A Steward is a legal entity — typically a foundation or a major corporate backer — that voluntarily takes on certain compliance responsibilities for an open source project, shielding individual contributors and maintainers from regulatory liability.

Red Hat, as the largest corporate contributor to the Ansible project, has stepped into this role. This means Red Hat will:

• Establish and maintain secure development practices for the Ansible ecosystem
• Manage vulnerability reporting to ENISA and national CSIRTs
• Implement Software Bill of Materials (SBOM) processes
• Document security practices and incident response procedures
• Absorb the administrative compliance burden that would otherwise fall on community volunteers

The Two Deadlines That Matter

What the Steward Role Covers — and What It Doesn't

This is the critical distinction that most coverage misses:

What Red Hat's Stewardship Covers

• Upstream Ansible project security processes — vulnerability management, incident response, SBOM generation for the open source project itself
• Community contributor protection — individual contributors and maintainers are shielded from CRA regulatory liability
• Security best practices — Red Hat will collaborate with maintainers to improve security hygiene across the Ansible ecosystem
• Vulnerability reporting to authorities — Red Hat will handle the mandatory reporting of actively exploited vulnerabilities to ENISA/CSIRTs on behalf of the project

What It Does NOT Cover

• Your organisation's CRA obligations as a manufacturer — if you build and distribute products that incorporate Ansible (including internal platforms, commercial products, or managed services), YOU are the manufacturer under CRA, not Red Hat
• Your commercial Ansible deployments — Red Hat's Stewardship covers the open source project. Your use of Ansible in production, your custom playbooks, your roles, your collections — those are your responsibility
• Red Hat Ansible Automation Platform (AAP) — the commercial product has its own compliance path as a manufactured product. The Stewardship role is for the upstream community project
• Your supply chain obligations — if Ansible is part of your software supply chain, you must still document it, assess its risks, and manage vulnerabilities in your own deployment context

What Enterprise Ansible Users Must Prepare Before September 2026

With the vulnerability reporting deadline 5 months away, here's what needs to happen now:

1. Know Your CRA Role

Determine whether your organisation is a manufacturer under the CRA. You likely are if you:

• Build software products that include Ansible components and place them on the EU market
• Develop internal platforms that use Ansible for automation and make them available to other entities
• Offer managed services that rely on Ansible automation
• Create and distribute Ansible collections, roles, or playbooks commercially

If you only use Ansible internally for your own infrastructure automation and don't distribute it as part of a product, your CRA obligations are lighter — but you should still prepare for supply chain due diligence requirements.

2. Inventory Your Ansible Footprint

• Which Ansible versions are deployed across your infrastructure?
• Which collections and roles do you depend on? Community collections, certified content, custom roles?
• What data does Ansible handle? Credentials, configuration data, secrets? This affects your risk classification.
• Which products in your portfolio incorporate Ansible automation? These are the products that fall under CRA manufacturer obligations.

3. Establish Vulnerability Management

By September 2026, you need the ability to:

• Track Ansible CVEs — subscribe to security advisories for Ansible core, collections you use, and Python dependencies
• Assess impact — when a vulnerability is disclosed, determine whether it affects your specific deployment and what the risk is
• Respond within CRA timeframes — actively exploited vulnerabilities require reporting within 24 hours of awareness (initial notification), 72 hours (detailed report), and 14 days (final report)
• Patch or mitigate — have a process for applying security updates to Ansible components in production

4. Generate Software Bills of Materials

The CRA requires SBOMs for products with digital elements. For Ansible deployments, this means:

• Ansible core version and its Python dependencies
• All installed collections with versions
• Custom roles and their dependencies
• Execution environment container images and their contents
• Any third-party modules or plugins

Red Hat's Stewardship will improve SBOM availability for the upstream project. But your deployment-specific SBOM — including your custom content — is your responsibility to generate and maintain.

5. Document Security Practices

Ensure you can demonstrate:

• How Ansible secrets are managed (Ansible Vault, external secret managers, credential injection)
• How Ansible access is controlled (who can run what, against which inventory)
• How Ansible execution is logged and audited
• How Ansible code changes are reviewed and approved (code review for playbooks and roles)
• How Ansible updates are tested before production deployment

The Broader Implications for Open Source in Regulated Enterprises

Red Hat's move is part of a broader strategy. According to their official CRA compliance page, Red Hat is expanding stewardship beyond Ansible to include Fedora and other critical upstream projects. They're also actively contributing to CRA standards development through the Eclipse Open Regulatory Compliance (ORC) Working Group and the Open Source Security Foundation (OpenSSF) — working to ensure CRA implementation reflects how modern software is actually built.

Key elements of Red Hat's CRA readiness approach that benefit enterprise users:

• Vulnerability management in standard formats — Red Hat's Product Security team provides analysis and remediation through CSAF (Common Security Advisory Framework) and VEX (Vulnerability Exploitability eXchange) formats, aligning with CRA's machine-readable reporting requirements
• Supply chain transparency via SBOMs — machine-readable Software Bills of Materials for Red Hat products, supporting CRA's auditability and provenance requirements
• Upstream security hardening — Red Hat is going beyond minimum stewardship requirements, actively working to harden security practices in upstream communities before code enters commercial products
• Standards influence — by contributing to ESOs and CRA implementing documents, Red Hat is shaping how CRA requirements will be interpreted and enforced

This creates a layered compliance model:

• Major corporate backers will assume Steward roles for their key projects — expect similar announcements from Google (Kubernetes, TensorFlow), Meta (PyTorch), and others
• Enterprises need to track Stewardship status for every open source component in their stack. Projects without a Steward may carry higher compliance risk.
• The Steward model creates a new layer of trust — but it's not a substitute for enterprise-level supply chain security. It's a complement.
• Community contributions may require new processes — Red Hat mentioned collaborating with maintainers on security practices. Expect contribution guidelines to evolve.

What to Do This Week

1. Share this with your compliance team — they need to understand the Steward/manufacturer distinction
2. Start the Ansible inventory — you can't manage what you can't measure. Know what Ansible components you run and where.
3. Review your vulnerability management process — can you currently track, assess, and respond to Ansible CVEs within CRA timeframes?
4. Identify your CRA role — are you a manufacturer, an open source contributor, or simply an end user? Each has different obligations.
5. Budget for compliance work — September 2026 is 5 months away. The work needed isn't free.

Red Hat's Stewardship is a responsible and welcome step. It protects the Ansible community and improves the security posture of one of the most widely used automation tools in the world. But it doesn't change the fact that enterprises using Ansible in production have their own CRA obligations to meet — and the clock is ticking.