DORA Compliance for Open-Source Platforms: FIPS 140-3, CMMC and PCI Patching

Which requirement asks for what: DORA, FIPS 140-3, CMMC, PCI and NIS2

Open source compliance looks different under each framework: each asks something different of an open-source platform, and AceMQ answers with evidence rather than a certificate. The table maps the five requirements buyers raise most to what the platform has to show and what AceMQ supplies.

We help you gather evidence. We do not certify your platform, and this page makes no certification claim. Your own compliance team and auditors decide whether the evidence satisfies a framework.

DORA compliance for the platform behind your payments and trading flows

The Digital Operational Resilience Act (DORA) is an EU regulation, Regulation (EU) 2022/2554, that sets one set of rules for how financial entities manage ICT risk: banks, insurers, payment firms, investment firms and others. Under its Article 64 it has applied since 17 January 2025.

A message broker or database is an ICT service like any other. DORA expects the financial entity to know which ICT third parties support its functions, to hold contracts that carry minimum provisions, and to test the systems those providers run. For a broker, that is an evidence question: what the support vendor commits to, how fast it responds, how patches are tracked, and what happens if you leave.

What a message broker support vendor should give you

• Service description — which platforms are covered, at which stage of the four-stage ladder, and what stays with you.
• Response times — 15 minutes for a P1, one hour for P2, four hours for P3 and next day for P4, as in our published SLA.
• Escalation path — named senior engineers, with direct escalation to the RabbitMQ core team where a problem needs it.
• Patch and CVE records — which advisories applied to your version, what was done and when.
• Access model — access scoped per stage, under your approval and audit trail at Stage 3.
• Exit — runbooks, topology documentation and monitoring configuration maintained as yours, so leaving is a handover rather than a rebuild.
• Resilience support — high availability and disaster recovery designed and tested, with failover runbooks.

What types of tests should financial entities perform under DORA?

DORA's testing rules are in Articles 24 to 26. Article 25 lists the kinds of tests a programme can use: vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, source code reviews where feasible, scenario-based tests, performance and end-to-end testing, and penetration testing. Article 24 requires appropriate tests at least yearly on the ICT systems that support critical or important functions, and Article 26 adds threat-led penetration testing at least every three years for the entities their authority identifies. Our part is to make the broker testable: failover that can be exercised, documented and repeated.

The regulation text is on EUR-Lex

For how this applies to payment, trading and insurance estates, see RabbitMQ and Kafka for financial services

FIPS 140-3 for RabbitMQ: what changed and what FIPSMQ covers

FIPS 140-3 is the current US federal standard for cryptographic modules. A module is validated by the Cryptographic Module Validation Program (CMVP), which NIST runs jointly with Canada's Cyber Centre, after testing by an accredited lab. It matters because US federal agencies and many regulated buyers require cryptography from validated modules, and because the standard is the one new validations are issued against.

Is FIPS 140-2 obsolete? NIST's CMVP set 21 September 2026 as the date FIPS 140-2 certificates move to its Historical list. Modules on that list may stay in existing systems, but a new system should be built on FIPS 140-3 modules. That date has now passed, so the question has moved from "when" to "which module".

FIPS 140-3 compliance applies to the cryptographic module, not to the whole middleware. A broker does not become "FIPS validated" because it runs on a validated library; what matters is which module performs the cryptography, how the broker is configured to use it, and what your auditor will accept as evidence. We scope that with you before we claim anything.

FIPSMQ is AceMQ's FIPS-compliant message broker: a hardened RabbitMQ distribution, delivered and supported by AceMQ, with 24/7 support behind it. It is the route when a contract or an accreditation requires FIPS cryptography on the messaging layer.

Details and coverage: FIPSMQ

Options side by side: FIPS RabbitMQ options compared

NIST's schedule is on the CMVP page

Patching compliance, CVE compliance and scanner findings

The question we hear most often is a scanner one: a Nessus scan flags the RabbitMQ version in production, and the only version publicly available is the one it dislikes. The community stops patching a series once it reaches end of life, so the finding cannot be closed by waiting. It closes with a build that has the fixes, plus a record that shows when and how.

How to fix CVE vulnerabilities, in short: identify which advisories apply to the version and configuration you actually run, patch or backport the fix, verify it, and keep the record. A secure patch is one that fixes the vulnerability without breaking the behavior your applications depend on, which is why backports are tested against the version they are for. AceMQ targets 72 hours for critical CVEs, depending on severity and the complexity of the backport. That is a target for the patch, not a promise of a fix time for an unknown fault.

End-of-life patch builds for open-source software beyond RabbitMQ come from AceMQ's OSSeva platform: osseva.io

RabbitMQ-specific detail, including live CVE data by version series, is on RabbitMQ compliance

Older RabbitMQ series: RabbitMQ extended LTS support

A patching case across 10,000+ RabbitMQ deployments: enterprise CVE patching strategy

A unified patching strategy across Kafka, RabbitMQ and IBM MQ: Kafka CVE patching and compliance

CMMC compliance and PCI patching for the messaging layer

CMMC Level 2 is built on the NIST SP 800-171 Rev 2 requirements. Where a broker carries or protects controlled unclassified information, two of them reach it directly: vulnerability remediation, and FIPS-validated cryptography to protect confidentiality. DFARS clause 252.204-7021 began appearing in Department of Defense contracts on 10 November 2025. DoD announced in July 2026 that it was suspending the next phase, which would have required third-party Level 2 certification, while it reviewed the program. Check the current position with your contracting officer, because the schedule has been changing. For the messaging layer, our side of CMMC is the same either way: patched builds, access scoped to what each stage needs and approved by you, and FIPS cryptography through FIPSMQ where it is required.

PCI DSS asks for security patches to be installed on a defined schedule. Requirement 6.3.3 sets a one-month window for critical patches from release, and your assessor will tell you whether high-severity patches fall in the same window for your environment. The window is a deadline you agree with your assessor; AceMQ's 72-hour target for critical CVEs sits inside it, and the record per advisory is the evidence.

NIS2, the EU directive on network and information security, applies to essential and important entities from the national laws that took effect from October 2024, and expects supply-chain security to be part of risk management. For NIS2 compliance, the evidence pack above serves the supplier file as it does for DORA.

Public-sector and defence buyers can start from FIPSMQ