How Apache NiFi helps meet DORA Article 8 and Article 9 for data flows
Apache NiFi can support the Article 8 and Article 9 requirements for data flows, but it covers only the technical part of them. DORA requires a financial entity to keep control over how its ICT systems move and protect data, and a NiFi flow is one of those systems. NiFi gives you the means to evidence several specific controls: transport encryption on every listener and remote connection, authentication through the supported providers (LDAP, OpenID Connect, SAML 2.0 or X.509 client certificates), flow versioning through the Flow Registry Clients for GitHub and GitLab, and an inventory of what each flow reads, writes and depends on. Those artifacts map to the Article 9(4)(d) expectations on strong authentication, cryptographic protection and recorded change management, and to the Article 8(4) expectation that interconnections be mapped.
Several obligations stay with the entity regardless of the tool. The information security policy, the risk assessment that sets encryption levels by data classification, the decision on which flows support critical or important functions, the patch policy, the yearly review under Article 8, the exit strategies for ICT third-party services under Article 28(8), and the supervisory relationship with the competent authority all belong to your organization. NiFi also does not decide whether a flow is in scope. Confirm with your compliance and legal teams which flows and which NiFi nodes fall under DORA before you design evidence around them.
DORA sets no certification scheme, and no product or implementer can certify compliance with it. Competent authorities supervise compliance, and independent auditors give any assurance opinion your board or supervisor asks for. DeployOpen plans, configures and hardens NiFi inside your infrastructure, documents the flows and their controls, and prepares the change records and configuration evidence that your auditors and supervisors will test. DeployOpen does not issue audit reports, attestations or certifications. Ask any implementation partner to show which evidence they will produce, who owns each control afterward, and how the evidence stays current after each flow change.
Mapping DORA Article 8 and 9 requirements to NiFi configuration
This table maps each DORA Article 8 and 9 requirement covered here to the NiFi capability that addresses it and the configuration to set. Read each row as a starting point for your control design, then confirm the setting against your own environment and your assessor's expectations. The main takeaway is that NiFi supplies the mechanisms, but the evidence (documented flows, reviewed changes and an up-to-date asset map) comes from how you run the platform.
| Requirement | NiFi capability | Configuration to set |
|---|---|---|
| Article 9(1) and (2): monitor security and functioning, protect data in transit and at rest | Provenance records data events; bulletins and metrics show flow health | Enable TLS on the UI and cluster traffic; confirm encryption of content and flow repositories at rest with your key process; route bulletins to monitoring |
| Article 9(4)(a) to (c): documented policy, risk-based network structure, limited access | Loopback binding by default; role-based authorization policies on flows and components | Keep the UI bound to 127.0.0.1 until security is configured; grant policies only for approved roles; document the access model in your ICT security policy |
| Article 9(4)(d): strong authentication | LDAP, OpenID Connect, SAML 2.0 and X.509 client certificate authentication; Kerberos is deprecated | Select one of the supported providers, enforce it for all users, and avoid the deprecated Kerberos provider for new deployments; confirm MFA behavior with your identity provider |
| Article 9(4)(d): protection of cryptographic keys | Sensitive property encryption and TLS keystores managed by the operator | Store keystores and keys outside flow definitions; restrict file permissions on the NiFi host; rotate keys under your documented procedure |
| Article 9(4)(e): risk-based change management, recorded, tested, approved and verified | Git-based Flow Registry Clients for GitHub and GitLab version flows in a repository | Require pull requests for flow changes; record approver and test evidence per change; promote versioned flows rather than editing production in place |
| Article 9(4) second subparagraph: segmentation and instant severing of connections | Cluster coordination through ZooKeeper or Kubernetes state; flows can be stopped per process group | Place NiFi nodes in segmented networks; document the procedure to stop or disconnect specific flows and nodes; test the procedure |
| Article 8(1), 8(4) and 8(6): asset identification, configuration and interdependency mapping, periodic update | Flow definitions and provenance show processors, connections and external endpoints | Export and store flow definitions as the configuration record; list each external system and remote site; refresh the inventory after every major flow change |
| Article 8(5): processes depending on ICT third-party providers | Provenance and flow definitions show calls to external SaaS, cloud and data providers | Tag flows that send data to third parties; record each provider, data type and location in your register; confirm contract terms with each provider |
How to protect NiFi data in transit and at rest for DORA Article 9
Article 9(4)(d) of DORA requires protection of data in transit and at rest, with encryption choices driven by data classification and ICT risk assessment, so the first decision is a classification of each flow before any configuration is touched. For each flow, the entity should record the data class, the hops it crosses, and the protection it requires on every hop. In NiFi, the UI and cluster traffic are the first hops to secure. Out of the box, NiFi binds to 127.0.0.1 when no security configuration is provided, so the UI is reachable only through the loopback interface. Production exposure therefore needs a deliberate security configuration: TLS on the HTTPS port, an authentication provider chosen from those the administration guide supports, and node-to-node TLS for cluster traffic. Confirm the keystore and truststore handling with your security team before rollout.
The data-in-motion hops between NiFi and source or destination systems are where most of the risk sits. Each processor that reads from or writes to an external system needs its own transport decision: TLS settings on the database, message broker, object store or SaaS connection, certificate validation rules, and the protocols and cipher suites the entity's policy permits. Where a flow carries sensitive content, the entity should decide whether TLS alone is sufficient or whether content must also be encrypted before it leaves NiFi. Those choices should be written into the flow documentation so that a reviewer can trace each hop back to its classification. Confirm the protocol and cipher behavior of each specific processor in the NiFi component documentation for your version, since defaults vary by component.
At rest, the sensitive areas are the repositories and the sensitive parameter values. The flow configuration file, the content, FlowFile and provenance repositories hold data and metadata that may be classified, so they need encrypted storage at the volume or disk layer and access restricted to the NiFi service account. Sensitive values such as passwords, API keys and connection secrets should be held in sensitive parameters or a supported parameter provider rather than in plain processor properties, and the key used to protect them must be stored and rotated under the entity's key management policy. Document where each key lives, who can read it, and how a rotation is tested, because Article 9(4)(d) expects key protection to be governed, not only enabled. Confirm the sensitive properties key configuration against the NiFi administration guide before choosing a storage design.
What NiFi evidence a DORA assessment can review
A DORA assessment will ask how data flows are defined, changed, monitored and mapped. The cards below list the artifacts a NiFi platform can produce for those questions, how to keep them, and what to check before showing them to an assessor. Sufficiency is always a judgment made by the competent authority or the financial entity's own auditors, not by NiFi.
Versioned flow definitions
Flow definitions can be versioned in a Git repository through the GitHub and GitLab Flow Registry Clients available in NiFi 2. The commit history and approved merge requests give a record of who changed each flow and when, which supports Article 9(4)(f) on recorded and approved changes. Check that production only runs versions that trace back to a reviewed commit, and retain the repository under your own backup policy.
Provenance records of data movement
NiFi provenance records events such as receive, send, route and modify for each FlowFile, which can show where regulated data entered, moved and left. These records help demonstrate the data transit controls under Article 9(1) and (4)(d). Decide retention periods and access rights for provenance data in advance, since it can itself contain sensitive content, and confirm how your deployment protects it.
Bulletins and monitoring metrics
Bulletins flag processor and component errors, and metrics show queue depth, throughput and node health. Together they support the continuous monitoring and control required by Article 9(1). Route bulletins and metrics to your central monitoring or SIEM platform, define alert thresholds, and keep alert history so you can show that issues were detected and handled.
Authentication and authorization exports
The configured identity providers (LDAP, OpenID Connect, SAML 2.0 or X.509 client certificates) and the access policies applied to flows, controller services and sensitive parameters define who can act on the platform. Exporting and reviewing these settings supports Article 9(4)(c) and (d) on strong authentication and limited access. Confirm that the Kerberos provider, which is deprecated, is not in use, and review exports on a fixed schedule.
Asset and dependency inventory from flow topology
The topology of process groups, processors, remote process groups and external connections maps the data flows, the systems they connect and their dependencies, as Article 8(4) and 8(5) require. A flow-level inventory should list every external endpoint, including third-party providers, and be refreshed after each major change as Article 8(6) requires. Ask your team to verify that the exported inventory matches the running cluster, because topology exports reflect only what is deployed.
Configuring NiFi flows for DORA change management and asset mapping
This sequence sets up a NiFi 2 platform that can be defended under DORA Article 9 and Article 8, from the baseline runtime and secured UI through versioned, reviewed flow changes to an inventory of every flow, endpoint and third-party connection.
Confirm the NiFi 2 platform baseline
Your platform engineers confirm that every node runs a Java 21 runtime, that the NiFi version is a supported 2.x release, and that the UI is served over TLS and bound to the network interfaces your operations team intends rather than the loopback default. Confirm the exact supported release and any Python processor version with the NiFi downloads page and administration guide before you build. The step closes when a configuration review shows the runtime, version and listener settings recorded in the change record for each environment.
Select and document the authentication provider
Your identity and security teams choose one of the providers NiFi supports, such as LDAP, OpenID Connect, SAML 2.0 or X.509 client certificates, and record why it meets the strong authentication expectation in Article 9(4)(d). Avoid building new access on the deprecated Kerberos provider. Check the provider settings with your identity team and confirm that administrator accounts are separate from individual operator accounts. The step closes when a test login succeeds through the chosen provider and the decision is recorded in the security policy.
Version flows in Git with reviewed changes
Your platform team connects NiFi 2 to a Git-based Flow Registry Client, such as the GitHub or GitLab clients, so every process group is saved as a versioned flow. Developers commit changes on branches, and a second person reviews and approves each merge before deployment, which provides the recorded, tested, approved and verified change trail that Article 9(4)(f) asks for. Confirm the client setup and access rights with your repository administrators. The step closes when a sample change shows a commit, a review record and a matching deployed version.
Separate development, test and production environments
Your platform team runs separate NiFi clusters or isolated namespaces for development, test and production, with different credentials, parameter contexts and network paths. Only the release pipeline or an approved operator promotes versioned flows into production, so developers do not hold direct production edit rights. Verify separation by checking that production parameter values and sensitive values are not present in development. The step closes when an access review confirms who can change each environment and the results are filed with the change records.
Choose the cluster coordination method
Your platform team selects how cluster nodes coordinate, either embedded or external ZooKeeper or Kubernetes using ConfigMaps or Leases, and records the choice with its failure behavior. This decision supports the network design and segmentation expectations in Article 9(4) because coordination traffic and node isolation affect how an affected part of the platform can be severed. Confirm the supported options and sizing questions with the NiFi administration guide and your infrastructure team. The step closes when a failover test shows the cluster electing a coordinator and the design is in the architecture record.
Set provenance and log retention
Your operations team sets provenance repository and application log retention to match the period your records and incident procedures require, and restricts read access to provenance data to named roles. Provenance and bulletin data serve as evidence for change verification and incident investigation, so retention must be set deliberately rather than left at defaults. Confirm the retention periods with your compliance and legal teams. The step closes when a retention setting is documented per environment and a restricted-role test confirms that only approved users can query provenance.
Build the Article 8 inventory of flows and connections
Your architecture and risk teams list every process group, the data it moves, each source and destination endpoint, and each connection to a third-party provider, including remote sites. They classify each flow by the business function it supports and map dependencies between flows, controllers and external services, which supports the identification and classification duties in Article 8(1) and 8(4). Ownership of each flow and provider should be named. The step closes when the inventory is stored under change control and a schedule for periodic updates and updates after major changes is documented.
Tie inventory updates to the change process
Your change board adds a rule that any new flow, endpoint, parameter or provider connection must update the inventory before approval, which meets the requirement to refresh inventories after major changes in Article 8(6). The inventory is reviewed against the Git history and the production flow list to catch unapproved edits. The step closes when a sample change request shows the inventory entry, reviewer sign-off and matching version in the registry.
Why the NiFi version matters for a DORA-regulated platform
NiFi 1.x can no longer be maintained, so staying on it is a patch and update policy problem under Article 9(4)(f). The NiFi project states that the 1.x line depends on Jetty 9.4, Spring Framework 5.3 and AngularJS 1.8, and those components cannot be upgraded within that line. The downloads page points users to NiFi 2, and the last minor release of the 1.x series is 1.28, with end of support for 1.28.1 listed as December 8, 2024. A financial entity that must document patch and update policies should therefore record the 1.x end of support as a known risk and attach a dated migration plan to it. The latest release the project lists is NiFi 2.12.0 (September 13, 2026), but confirm the target version on the project's own Apache NiFi download page before you fix the plan, since release lines move.
The migration guidance sets prerequisites that shape the plan. Existing 1.x flows must first be brought to NiFi 1.27.0 before moving to 2.0.0, and the flow configuration file changes from flow.xml.gz to flow.json.gz. Flows and parameter setups that reference the variable registry expression language scope need rework, because that scope was removed in NiFi 2.0 and replaced by an ENVIRONMENT scope. Distributed map cache components were also renamed, so any controller service configuration that names them must be updated. Each of these changes alters the flow inventory you must keep under Article 8, so update the asset and dependency records as part of the migration rather than afterward.
Plan the Registry dependency now, not at the end of the migration. NiFi Registry is deprecated and planned for removal in NiFi 3.0, so the version-control approach you adopt for change management should not depend on it indefinitely. The NiFi 2 Flow Registry Clients for GitHub and GitLab give a Git-based option that can support the recorded, tested and approved change trail Article 9(4)(f) expects. Ask your team to confirm which versioning path will carry the flows after migration, and record the decision with its approval and test evidence.
What NiFi does not cover for DORA
NiFi moves and protects data, but several DORA duties sit with the entity's governance, its contracts and its supervisory relationship. The cards below cover items the platform cannot supply, and they assume that your team still controls the systems, people and suppliers around each flow.
Information security policy and risk assessment
Article 9(4)(a) requires a documented information security policy, and Article 8(2) requires continuous identification of ICT risk sources and yearly review of risk scenarios. NiFi can enforce settings that the policy names, such as TLS on every hop and restricted access to flows, but it cannot write the policy or assess the threats facing your entity. Check that each NiFi control traces back to a named policy clause and a documented risk scenario.
Incident management and reporting
Chapter III requires classification, management and reporting of ICT-related incidents within the timelines the regulation and its technical standards set. NiFi bulletins, provenance and logs can supply evidence for an investigation, but a flow log does not decide severity or reach a regulator. Confirm which NiFi signals feed your incident process, who receives them, and how provenance records are retained long enough to support a report.
Register of information and exit strategies
Article 28(3) requires a register of information on all contractual arrangements for ICT services, and Article 28(8) requires documented, tested exit strategies for services supporting critical or important functions. A NiFi flow that calls a SaaS API or cloud store creates a third-party dependency that must appear in that register. Map each external endpoint in your flows to a provider entry, then confirm who can rebuild the flow if that provider exits.
Contract terms for ICT services
Article 30(2) requires every ICT services contract to state where services are provided and data processed, to give advance notice of changes, and to cover data return on insolvency or termination. A NiFi deployment hosted by a cloud or managed service provider needs these terms in its contract, and the flows you design must respect the processing locations named in it. Ask legal and procurement to check hosting regions, subprocessors and data return before the platform goes live.
Threat-led penetration testing
Chapter IV requires digital operational resilience testing, and entities identified for threat-led penetration testing must follow the TLPT requirements in Article 26. Testing NiFi's flows, interfaces and hardening is a useful input, but it does not replace a TLPT run by the entity and its testers under the regulation. Confirm whether your entity is in scope for TLPT and, if so, whether NiFi's exposed endpoints and cluster nodes are in the test scope.
Supervisory attestation and outcomes
DORA sets no certification scheme, and competent authorities supervise compliance using their Article 50 powers. The only authority-issued attestation the regulation provides for is that a threat-led penetration test met its requirements (Article 26(7)). No authority issues an attestation for NiFi itself, so do not present the platform as certified. Use your own evidence, such as configuration baselines, change records and test reports, to show how your entity meets its obligations.
Questions financial entities ask before scoping NiFi for DORA
What drives the effort of a DORA-aligned NiFi configuration?
The main drivers are the number of data flows in scope, how many of them support critical or important functions, and how many environments (development, test, production, disaster recovery) need the same controls. Effort also rises when flows cross trust boundaries, such as connections to third-party providers or other financial entities, because each connection needs documented encryption, authentication and ownership. Existing gaps matter too: a cluster with unmanaged certificates, flows edited directly in production, or no provenance retention policy takes more work than a platform already run under change control. Ask any provider to break the quote down by flow inventory, security configuration, change management setup, evidence preparation and knowledge transfer, so you can see which items recur.
Can our in-house team configure NiFi for DORA themselves?
Often yes, if the team already runs NiFi or similar platforms and has the security and compliance skills to map Article 8 and Article 9 requirements to concrete settings. The work touches TLS on every hop, authentication providers, authorization policies, sensitive value handling, Git-based flow versioning and cluster coordination, so the team needs experience with each of these. Many entities split the work: internal staff own the asset inventory and risk decisions, while an implementation partner configures the platform and documents the result. Be realistic about capacity, since the same engineers usually run production operations and cannot easily absorb a first-time build without a plan.
What does the work need from our organization?
The work needs decisions and records from people in the entity, not only from the platform team. You will need a data classification scheme that tells engineers which flows carry sensitive or critical data, a flow inventory with owners and dependencies, named risk owners who accept residual risk, and change approvers who review flow changes before they reach production. Article 8 also asks for mapping of remote sites and third-party interconnections, which often requires input from procurement and business continuity teams. Confirm these owners and their time commitments before the build starts, because delays in these decisions usually extend the schedule more than technical work does.
How long does a DORA-aligned NiFi project take?
No duration figure is supplied for this work, so the timeline depends on the written scope. Duration generally grows with the number of flows, the number of environments, the degree of existing documentation and how many approval steps the change process requires. A small set of flows in one environment is a different project from dozens of flows across production, disaster recovery and remote sites. Ask for milestones tied to deliverables, such as inventory completed, security baseline applied, change workflow tested and evidence pack delivered, and confirm which of these depend on your staff's availability. The quote follows the written scope.
Is Apache NiFi itself licensed, and does it have a paid edition?
Apache NiFi is released under the Apache License 2.0 (SPDX identifier Apache-2.0), and the Apache Software Foundation project does not offer a paid edition. Your costs therefore come from infrastructure you run, staff or partner time, and any third-party components you choose to add, such as external identity providers or storage. Confirm the licensing of any extension, connector or commercial service you add to the platform, because those carry their own terms. For version planning, note that the project's download page states NiFi 1.28 is the last minor release of the 1.x series and encourages users to move to NiFi 2, which affects how long a current configuration remains supported.
Can DeployOpen certify that our NiFi platform is DORA compliant?
No. DeployOpen does not issue audit reports, attestations or certifications. DORA sets no certification scheme, and competent authorities supervise compliance using their own powers. DeployOpen can plan and implement the NiFi configuration, document the flow inventory and change process, and prepare the controls and evidence that your internal assurance functions and external auditors need to test. Your compliance function remains accountable for the entity's position under DORA, and any independent assessment is performed by the auditors or bodies you engage. Ask any partner to show in writing exactly which evidence they will deliver and which assessments remain your responsibility.
What evidence will we have after the NiFi configuration is complete?
The evidence should map to the Article 8 and Article 9 requirements in the form your supervisors and auditors will test. Typical items include the flow inventory with classifications and dependencies, a record of TLS and authentication settings per flow, authorization policies, the version history of flows in your Git repository with approvals, provenance retention settings, and documented procedures for patching, backups and isolation. Ask what each item looks like in your environment, who keeps it current after handover, and how often it is reviewed. Evidence that is only produced at audit time tends to be incomplete, so agree on a recurring collection process during scoping.
How DeployOpen scopes DORA-aligned NiFi work
DeployOpen starts every DORA-aligned NiFi engagement with a written scope that names the flows in question, the NiFi version and deployment topology, the sites and networks involved, and the business functions each flow supports. The scope also states which deliverables the client receives, such as flow documentation, configuration baselines, an Article 8 asset and dependency inventory, and an evidence pack mapped to Article 9. Because most engagements are fixed-scope, the deliverables and timelines are agreed before work begins, and a quote follows from that written scope. Clients should ask for the scope to list which flows and nodes are excluded, since those exclusions determine what the evidence covers. On the security side, the work covers the NiFi configuration that Article 9 expects a regulated entity to control: TLS on cluster and client connections, an authentication provider chosen from the options NiFi supports (such as LDAP, OpenID Connect or SAML 2.0), authorization policies scoped to the roles that need them, and sensitive property handling for credentials and keys. Flow definitions are kept in a Git repository through a Flow Registry Client, so each change to a flow goes through a reviewed commit and can be traced to an approver and a deployment. Clients should confirm the registry platform they use and who holds merge rights to the production branch, because those roles decide whether the change management evidence holds up. The Article 8 inventory is built from the flow designs, cluster topology and external connections DeployOpen documents during the engagement, and it maps each NiFi component to the ICT-supported functions, the data it handles and its upstream and downstream dependencies. Retainers can then cover upgrades, periodic inventory refreshes after major changes, and continuous testing of the platform. DeployOpen prepares systems, controls and evidence for supervisory or audit review, but it does not issue audit reports, attestations or certifications. Those come from the competent authority or an independent auditor the client engages.
