Apache NiFi for CMMC: which requirements its flows can support
Consider a defense contractor or subcontractor whose NiFi flows move controlled unclassified information (CUI) between an enclave and a corporate system, or between two enclaves. Apache NiFi can support SC.L2-3.13.8, AU.L2-3.3.1 and AC.L2-3.1.1 through configuration, but NiFi cannot satisfy any of them alone. A flow platform is one component of evidence, not a compliance outcome. Each requirement is assessed across people, process, technology and documentation, and the assessor will look at the whole system boundary around the flows.
Level 2 of the CMMC Model is the 110-requirement set that matches NIST SP 800-171 Rev. 2, as incorporated by 32 CFR 170.14. Under the CMMC Scoring Methodology in 32 CFR 170.24, SC.L2-3.13.8 is worth 3 points, AU.L2-3.3.1 is worth 5 points and AC.L2-3.1.1 is worth 3 points. Each of the three must be MET, because 32 CFR 170.21(a)(2) does not allow requirements worth more than 1 point on a plan of action and milestones. Assessments are scored against the assessment objectives in NIST SP 800-171A, and evidence must be in final form. DeployOpen prepares systems, configurations and evidence for assessment, but it does not issue certifications or assessment results. Independent C3PAOs perform Level 2 certification assessments.
The Department of War suspended CMMC Phase II on 13 July 2026, so certification requirements are on hold for now. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place, so confirm your current obligations with your contracting officer and counsel before relying on that timing. Ask your team to document which flows cross the CUI boundary and which NiFi nodes, registries and identities touch them, because that inventory determines the scope every later control is measured against.
How each CMMC requirement maps to NiFi capabilities and configuration
This table compares each CMMC Level 2 requirement in scope for CUI flows with the NIST SP 800-171A objectives it must meet, the NiFi capability that addresses it, and the configuration to set and confirm. Use it as a worksheet, since a requirement is scored MET only when every objective has evidence in final form. Confirm each configuration key against the NiFi version you run.
| Requirement and assessment objectives | NiFi capability | Configuration to set and confirm |
|---|---|---|
| SC.L2-3.13.8: identify the cryptographic mechanism or physical safeguard, then implement one during transmission | TLS on the HTTPS interface, site-to-site remote ports and node-to-node traffic, with client certificates where supported | Set nifi.web.https.host, nifi.remote.input.secure=true and nifi.security.needClientAuth=true, then check TLS on every hop in each flow |
| SC.L2-3.13.8 (cont.): confirm no unencrypted path carries CUI between flows, sites or external systems | Processor and controller service TLS settings for databases, message brokers and object storage | Inventory each processor that sends CUI and record its protocol, certificate and cipher settings |
| AU.L2-3.3.1: specify the event types and content audit records need, then generate records containing that content | Provenance events for data movement, bulletins for component errors and user action history for configuration changes | Set provenance retention with nifi.provenance.repository.max.storage.time, and forward application and user logs to your SIEM |
| AU.L2-3.3.1 (cont.): define and meet retention requirements for audit records | Provenance and log files are records only if they are kept and protected for the period you define | Document retention periods, test log rollover and restrict who can read or delete provenance data |
| AC.L2-3.1.1: identify authorized users, processes and devices, then limit access to each group | LDAP, OpenID Connect, SAML 2.0 or X.509 authentication, with authorizer policies for users, groups and components | Replace the single-user provider using nifi.security.user.login.identity.provider and nifi.security.user.authorizer, and review authorizations.xml |
| AC.L2-3.1.1 (cont.): limit access for authorized devices and the processes that act for users | Client certificates identify nodes and remote systems; restricted policies limit what each identity can change | Bind the UI to an approved interface, remove broad policies and export the policy set for assessor review |
Protecting CUI in transit between NiFi nodes and external systems
SC.L2-3.13.8 requires cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission, unless alternative physical safeguards protect that data. NIST SP 800-171A breaks this into three assessment objectives: identify the cryptographic mechanisms and any alternative physical safeguards intended to prevent disclosure, then implement one or the other during transmission. For a NiFi flow, the assessor will expect you to name each path CUI takes and show the protection on that path. Before you choose a mechanism, build an inventory of every hop: the NiFi UI and REST API, the cluster protocol between nodes, site-to-site connections to other NiFi instances, and processor connections to databases, object storage, message brokers and SaaS endpoints. A hop missing from that inventory is a hop the assessor may find later, so treat the inventory as a control artifact and keep it under change management.
Each hop needs a documented decision. For the UI and API, the relevant configuration lives in the nifi.properties keys for the HTTPS port and the keystore and truststore. Site-to-site and cluster traffic use their own TLS settings, and processors such as database or cloud storage connectors take their TLS options from their controller services or processor properties. Where a hop cannot be encrypted, such as a legacy system on a physically controlled segment, record the alternative physical safeguard and the evidence that it operates. Do not assume that a secure default exists on every hop; confirm each property against the NiFi administration guide for your version rather than copying settings between flows.
FIPS-validated cryptography is a question to settle with your assessor and your own environment, not a checkbox. Confirm which validated modules the assessor will accept, then verify that NiFi actually uses them. That check spans the Java runtime (the NiFi administration guide lists Java 21 as the minimum), the JVM security providers and the operating system crypto policy, which together determine which algorithms and key sizes a TLS handshake can negotiate. Record the configuration, the test results showing the negotiated protocol and cipher on each hop, and the validation status of the modules in your own scope. Ask your assessor whether they will accept the vendor's documentation alone or expect evidence from your running systems.
What audit evidence NiFi produces and how to keep it final
A NiFi flow produces several distinct records that an assessor can examine: data movement history, operational alerts, flow change history, access configuration and retention settings. Each one answers a different part of AU.L2-3.3.1 and AC.L2-3.1.1, and each must be captured in final form before an assessment begins.
Provenance events as movement records
NiFi provenance records events such as receive, send, fork, join and drop for each FlowFile, which shows where CUI came from, where it went and which component handled it. Decide which event types and attributes your organization needs to show for 3.3.1, then confirm that the chosen provenance repository settings keep those records long enough to answer an investigation. Test a sample transfer end to end and export its lineage as evidence. Provenance records may contain CUI in attribute values, so protect the repository itself.
Bulletins and logs for unauthorized activity
Bulletins surface processor warnings and errors in the UI, while application, user and request logs record system activity that could reveal unlawful or unauthorized use. Route these logs to a central store that your monitoring team reviews, and define who receives alerts and how fast they respond. Confirm that log content includes user identity, time, action and outcome. Keep proof that the review process ran, not only that the logs exist.
Flow definitions versioned in Git
Flow Registry Clients for GitHub and GitLab store each versioned flow in a Git repository, so commit history, author and review records show who changed a flow and when. Require reviewed merge requests for production flows and keep the approval record with the commit. Check that the repository itself meets your access and retention rules, because it holds the logic that moves CUI. Export the commit log for the assessment period as evidence of controlled change.
Authentication and authorization configuration exports
Exports of the authentication provider settings, such as LDAP, OpenID Connect or SAML 2.0, and of the policies that grant read, write and operate rights on each process group show which users and devices may reach each flow. Store these exports as versioned files and record each change with its approver. Compare the exported policies against your list of authorized users and processes to test 3.1.1. Also capture proof that the UI and API bind only to the intended interfaces.
Retention settings and their justification
Retention for provenance, logs, bulletins and Git history is set in NiFi configuration and in your log platform, and it is not a NiFi default you can assume. Write down the retention period for each record type, the reason for it, and the investigation scenarios it must support. An assessor will check that the configured values match your written standard. Organization-defined retention is a decision you must make and document, not something this page can specify.
Final-form evidence for each requirement
A requirement counts as MET only when every applicable NIST SP 800-171A objective is satisfied with evidence in final form, not drafts. Exports taken during a build, unsigned approvals and screenshots without dates are weak evidence. Set a dated evidence package for each control, record who produced it, and re-collect it after any change to the flow or its settings. Confirm the exact evidence expectations with your C3PAO or assessment guide before the assessment.
Configuring NiFi flows for CMMC evidence
This sequence turns a NiFi deployment that moves CUI into a set of settings and records an assessor can test against the NIST SP 800-171A objectives behind SC.L2-3.13.8, AU.L2-3.3.1 and AC.L2-3.1.1. Each step ends with an artifact that shows the control is in place and can be reviewed later.
Scope CUI flows and the assessment boundary
Start by listing every flow, processor group, controller service and NiFi node that receives, transforms, stores or forwards CUI, along with the systems at each end. Record which NiFi nodes, ZooKeeper or Kubernetes state stores, and provenance and log storage fall inside the assessment boundary, and which external systems are connected. Confirm with your assessor and your CMMC scope documentation how CUI is defined in your environment, and confirm whether any cloud service that stores or processes CUI must meet the FedRAMP Moderate requirement. The output is a boundary diagram and a flow inventory that every later step references.
Establish the NiFi 2.x baseline
Confirm that the nodes run a supported NiFi 2.x release on Java 21, the minimum runtime listed in the administration guide, and that the flow definition is stored as flow.json.gz rather than flow.xml.gz. If the platform still runs NiFi 1.x, plan the migration through the documented 1.27.0 step first, since 1.x can no longer be maintained. Record the exact release, JDK build and flow file name for each node. Check the release notes and the Migration Guidance for the installed version before you rely on any setting described here.
Enable TLS and remove loopback-only binding
Configure keystore and truststore settings so that the web UI, cluster protocol, site-to-site ports and every external connection use TLS. NiFi binds to 127.0.0.1 when no security configuration exists, so set the bind address and host properties deliberately for the network design you approved. Confirm the protocol versions and cipher policies against the administration guide and your cryptographic standard. The check that closes this step is a scan of each listening port showing encrypted sessions only, with the certificate chain and key storage documented.
Choose an authentication provider and map users to policies
Select one provider from the options the administration guide supports (single-user, LDAP, OpenID Connect, SAML 2.0 or X.509 client certificates) and avoid the deprecated Kerberos provider for new work. Create user groups that match job roles, then grant read, write and operate permissions on specific process groups rather than on the root canvas. Keep administrator rights separate from flow authors and restrict the ability to view sensitive parameters. The output is an access matrix that lists each user group, the process groups it can change, and the approval that granted it.
Configure provenance and log retention
Set provenance repository and application log retention to the period your CUI policy and the audit objectives require, and confirm which event types the flows record. Specify the audit content each record must contain, including the actor, time, component and action, and verify that provenance events include the content you named. Send logs to a protected store that the flow authors cannot edit, and document who can search them. The check is a test event that appears in provenance and in the central log store with the required fields, plus a documented retention decision.
Version flows and require reviewed changes
Connect each production process group to a Flow Registry Client such as the GitHub or GitLab clients in NiFi 2, so that every flow change is committed to a versioned repository. Protect the main branch, require a reviewed merge before a version is deployed to production, and keep the review record with the commit. Note that NiFi Registry is deprecated and planned for removal in NiFi 3.0, so avoid building new controls on it. The output is a change log where each production flow version traces to a reviewer and an approval.
Collect evidence against each 800-171A objective
Build an evidence sheet with one row for each assessment objective in NIST SP 800-171A for 3.13.8, 3.3.1 and 3.1.1, listing the setting, the screenshot or configuration export, and the date it was captured. Evidence must be in final form, since drafts do not satisfy an objective under 32 CFR 170.16 and 170.24. Ask your assessor which artifacts they accept for each objective, and re-collect evidence after every NiFi upgrade or configuration change. The sequence is complete when every objective maps to at least one current artifact that a reviewer can open without access to the live system.
Questions buyers ask about NiFi and CMMC Level 2
Is Apache NiFi CMMC certified?
No. NiFi is open-source software under the Apache License 2.0, and neither the Apache Software Foundation nor DeployOpen issues CMMC certification for a product. Level 2 assessments examine your environment: how your organization identifies and limits access, encrypts CUI in transit, and generates and retains audit records across the systems that handle CUI. Certification for Level 2 is performed by C3PAOs authorized or accredited by The Cyber AB, so NiFi can support your evidence but cannot carry the requirement on its own. Ask your assessor early which NiFi configuration, logs and records they expect to see for SC.L2-3.13.8, AU.L2-3.3.1 and AC.L2-3.1.1.
What drives the cost of a NiFi CMMC data flow project?
The main driver is how many flows carry CUI, how many enclaves and hops they cross, and how deep the evidence has to go. Each flow needs a documented data path, transport encryption on every hop, provenance and audit logging settings, and access rules tied to named roles. Costs rise with the number of source and destination systems, custom processors, identity integrations and clustering, and with the number of assessment objectives you must evidence. Some costs are one-time, such as design, build and validation. Others recur, such as patching, certificate renewal, log retention and periodic review of access. Ask any provider for a written scope listing flows, environments, deliverables and what is excluded before comparing quotes.
How does the Phase II suspension affect our timing?
The Department of War suspended CMMC Phase II on 13 July 2026, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place, and the Department started a 60-day review by a CMMC Reform Task Force. Because the schedule is under review, confirm the current requirements with your contracting officer and sponsor before setting a deadline. Whatever the schedule, SC.L2-3.13.8 cannot sit on a POA&M, so protecting CUI in transit should be in place before any assessment.
What must our team provide before a NiFi CMMC engagement starts?
Your team should bring four inputs to scoping. First, a flow inventory listing each flow, its sources, destinations, data types and whether it carries CUI. Second, the identity source you intend to use, such as LDAP, OpenID Connect, SAML 2.0 or X.509 client certificates, and who administers it. Third, scope decisions: which NiFi nodes, registries, repositories and log destinations sit inside the CMMC assessment boundary, and which cloud services store or process CUI. Fourth, the people who will approve access and flow changes. Cloud services that store or process CUI must be FedRAMP Authorized at the Moderate baseline or higher, or meet equivalent requirements, so confirm those providers before design begins.
Can our own team build and maintain NiFi CMMC flows internally?
Often yes, if the team already runs NiFi and understands the assessment objectives in NIST SP 800-171A. The work that is hardest to do internally is usually the evidence: mapping each control to a configuration, a log or a procedure, and keeping that evidence in final form, since a requirement is MET only when all applicable objectives are satisfied with final evidence, not drafts. Teams without prior NiFi security work often underestimate TLS on every hop, authorization policies, sensitive value handling and log retention. You can split the work: your team owns flow content and operations, while a partner handles hardening, validation and evidence structure. Decide that split before the build starts.
What does a fixed-scope written quote for this work include?
A fixed-scope quote follows from a written scope agreed before work starts. It should list the flows in scope and their data paths, the NiFi environments and clusters, the encryption and identity configuration to be implemented, the audit logging and retention settings, the access model, the evidence to be produced and the handover documentation. It should also state what is excluded, such as assessor fees, cloud service authorization, third-party connectors, and ongoing operations. Ask whether the quote covers testing and validation of each control, how change requests are handled, and what happens if the flow inventory grows. DeployOpen does not publish a price list, so a quote is the only way to compare scopes.
Which NiFi features matter most for SC.L2-3.13.8 and AU.L2-3.3.1?
For transmission protection, the key items are TLS on every site-to-site and remote connection, correct certificate handling, and a documented decision for any hop that relies on physical safeguards instead of cryptography. For audit records, the key items are provenance settings that record the events you define, bulletin and log retention, and protected storage of those records. Access control under AC.L2-3.1.1 depends on the authentication provider, role-based authorization and restricted administrative actions. Confirm the exact property names, versions and behavior against the NiFi administration guide for your release, because NiFi 1.x reaches end of support and NiFi 2 changes several configuration files.
What changes for your team once CUI flows are in scope
Once a NiFi flow carries CUI, every flow change becomes an assessed change. Flow definitions should live in a Git repository through a Flow Registry Client, so that each modification to a process group has a commit, a reviewer and an author on record. Confirm who may approve changes, whether the approver is separate from the person who built the flow, and how emergency changes are recorded and later reviewed. Developers should not edit flows directly on production nodes. The same discipline supports the access review under AC.L2-3.1.1, because the people allowed to change a flow are part of the authorized-user set the assessor will ask about.
Access reviews need to cover more than the NiFi UI. The authorized users, the processes acting on their behalf and the devices allowed to connect each need a documented list, and the NiFi policies, identity provider groups and certificate trust settings must match that list. Single-user authentication is not an acceptable basis for a CUI environment, so confirm which of the supported providers (LDAP, OpenID Connect, SAML 2.0 or X.509 client certificates) your organization will use and who administers the group mappings. For log review under AU.L2-3.3.1, decide which NiFi events are reviewed, by whom, how often, and where the records are retained. Provenance and bulletins help investigators, but they only count as audit records if the retention and content requirements are defined and met.
The NiFi 2.x upgrade interacts with assessment timing. NiFi 1.x can no longer be maintained because of its Jetty, Spring and AngularJS dependencies, so a CUI environment that stays on 1.x will eventually run unsupported software. Plan the migration before the assessment rather than during it, because flow and configuration changes made mid-assessment must be documented and their evidence finalized. Confirm the upgrade sequence in the NiFi migration guidance, the Java 21 runtime requirement and the change in flow configuration file format, and re-test the encryption, logging and access controls after the move. The CMMC status of CUI flows depends on the evidence in final form at the time of assessment, so an upgrade that is only partly finished at that point will be scored against its current state.
How DeployOpen works on this
DeployOpen plans, builds, documents and hands over Apache NiFi flows that carry CUI, with the transmission, audit and access settings written against the assessment objectives your assessor will test. We work inside your own infrastructure and deliver evidence that your team can maintain after the engagement ends.
How we scope
- We inventory every flow that touches CUI, its sources, destinations and the hops between them.
- The written scope names the NiFi version, cluster topology, authentication providers and in-scope hosts before work starts.
- Scope also records which cloud or external services receive CUI, so their FedRAMP or equivalent status is confirmed up front.
How we build
- We configure TLS on every hop, with cryptographic mechanisms documented against SC.L2-3.13.8 and the physical safeguards you rely on.
- We set provenance, bulletin and log content to match the event types and retention you define for AU.L2-3.3.1.
- We enforce authorized users, groups and certificate-based device access in NiFi policies to support AC.L2-3.1.1, then test each boundary.
How we hand over
- You receive flow documentation, configuration baselines and a mapping from each requirement to the settings and evidence that support it.
- Flow definitions are versioned in a Git repository through a supported registry client, with the change approval steps written down.
- Runbooks cover certificate renewal, access reviews, log retention checks and how to re-test after a NiFi upgrade.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the handover.
- Retainers can cover NiFi 2.x patch reviews and re-verification of flows whenever the CMMC assessment method or scope changes.
- Final assessment decisions rest with the independent assessor, and we confirm with your assessor which evidence they expect.
