CMMC Level 2 open-source tools: what each covers and what it costs to adopt

A license tells you what you may do with a piece of software: use it, modify it, and pass it on to others. It does not tell an assessor whether your environment meets a CMMC Level 2 requirement. The tools in this section carry different licenses. Keycloak is Apache-2.0, Wazuh and chrony are GPL-2.0-only, FreeIPA is GPL-3.0-or-later, OpenSCAP is LGPL-2.1-or-later, and Greenbone Community Edition is AGPL-3.0-or-later. Each license sets different conditions when you distribute the software or change its source, and those conditions are where the differences matter. Running a tool inside your own enclave for your own use usually triggers fewer obligations than shipping it to customers, but that depends on how you deploy and modify it. Have counsel confirm the obligations that apply to your specific deployment, especially if you customize code or provide the platform as a service to other organizations.

Open-source licensing and CMMC are separate questions. Choosing a tool under an acceptable license does not satisfy identification and authentication, audit logging, or vulnerability scanning requirements. The organization still has to configure the tool, keep its records, and show assessors evidence in final form that the relevant objectives in NIST SP 800-171A are met. The licensing question is a procurement and legal check, and the compliance question is a configuration and evidence check. Keep the two records apart so that a license review does not get mistaken for a control assessment.

License terms are not the only thing to confirm. Security Onion Pro features require a purchased license, including OIDC single sign-on, FIPS and STIG hardening, and the Security Onion API. If your design depends on any of these, the community edition will not supply them without a paid subscription. Before you finalize the architecture, record which edition you run, list every feature your control design depends on, and confirm each one is included in that edition. The Security Onion license documentation is the place to start, and the vendor should confirm the terms for your use in writing.

DoD does not certify, endorse or rank software for CMMC, so no tool in this topic is a "CMMC approved" product. The CMMC final rule states that DoD cannot comment on specific products, that a wide range of technologies may be used to implement the CMMC requirements, and that DoD will not publish a list of approved tools. The practical consequence is that you choose tools yourself and must justify them through the evidence they produce. Keycloak for single sign-on, Wazuh for log analysis, OpenSCAP for configuration checks, Greenbone for vulnerability scanning and chrony for time synchronization are all candidates, but none of them earns credit by name. Read the CMMC final rule before you treat any vendor claim as settled.

Managed service providers often ask whether their own tools will be treated as security protection assets, and whether that brings them into scope. The rule's position answers the question indirectly. An assessor does not check a product against a list. The assessor checks whether each requirement's assessment objectives in NIST SP 800-171A are met with final evidence in the environment being assessed. A logging platform is judged by whether it retains audit records, protects them and supports review, and by where those records sit relative to the CUI boundary. A scanner is judged by whether its reports drive tracked remediation. Before deployment, document for each tool which requirement it supports, who administers it, where its data is stored and whether it is inside the assessed boundary. Those four answers determine how the tool is treated, far more than its license does.

The requirement set matters as much as the tool set. Level 2 uses the same requirements as NIST SP 800-171 Rev. 2, which 32 CFR 170.14(c)(3) identifies as the Level 2 security requirements, and 32 CFR 170.4 counts 110 of them. On 13 July 2026, the Department of War said it will enforce Rev. 2 in the interim, even though NIST withdrew that revision in favor of Rev. 3. The same day, the Department suspended CMMC Phase II, which had been scheduled to start on 10 November 2026. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. Confirm the current status with your contracting officer and the DoW CIO's CMMC pages, because the eCFR text still shows the original schedule. Map your tools to Rev. 2 requirements now so the mapping remains valid whichever schedule applies.

An assessor tests each Level 2 requirement against the assessment objectives in NIST SP 800-171A, and a requirement counts as MET only when every applicable objective is satisfied with evidence in final form, not drafts (32 CFR 170.16, 170.17 and 170.24(b)). Tool output does not meet a requirement by existing. It becomes evidence only when it shows a specific objective being met, for a defined scope, at a known point in time. Before you collect anything, map each tool to the objectives it supports and confirm with your assessor, or your C3PAO if you expect a certification assessment, what form they will accept. Expect them to ask for the configuration that produced the output as well as the output itself.

Several tools produce evidence that maps directly to objectives. Wazuh alerts in alerts.json and the dashboard records show that audit events were collected, reviewed and alerted on. OpenSCAP reports in HTML, ARF or XCCDF format show a pass or fail result for each rule in the profile you applied, so keep the profile file and version with the report. Greenbone scan reports should state the feed date, because an assessor will ask whether the vulnerability tests were current when the scan ran. chrony sync status from chronyc tracking and chronyc sources supports time stamp requirements. Keycloak configuration exports and FreeIPA access control records show MFA settings, password policies, group membership and delegated administration. Confirm each export format with your assessor before you rely on it.

An assessor will also test whether the controls operated over time, not only that a tool was installed, so plan for recurring records such as scan schedules, review logs, alert triage tickets and periodic configuration snapshots. Your system security plan must describe the tools, their configuration and their responsibilities in the same terms the evidence uses. If the plan says Wazuh reviews events daily and the alert history shows gaps, the mismatch is a finding. Review the plan whenever a tool is upgraded, reconfigured or replaced. Also confirm licensing before you commit to a design: for example, the Security Onion Pro features listed in its documentation require a purchased license, and an assessor will expect you to know which capabilities you depend on.