How Apache NiFi helps meet NIS2 cryptography and supplier data exchange duties
If your organization is an essential or important entity under NIS2, you need defensible encryption on every data exchange with suppliers and a paper trail that shows how those controls are chosen and operated. Apache NiFi can support the technical side of that work: it provides transport encryption through TLS, user and client authentication, versioned flows and provenance records of what data moved and when. It does not supply a cryptography policy, a key management process, supplier contracts or a compliance certificate. NIS2 creates no certificate of compliance. National competent authorities check compliance through inspections, audits, scans and information requests. DeployOpen plans and configures systems, controls and evidence for these reviews, but does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work.
Under Article 21(2)(h), your organization needs policies on the use of cryptography. Implementing Regulation (EU) 2024/2690 expects a policy that sets approved protocols, algorithms and cipher strength for data at rest and in transit, based on asset classification. NiFi configuration should follow that policy, not define it. In practice, decide which protocols and cipher suites each flow may use, then confirm them in NiFi's TLS settings and in every remote endpoint a processor calls. Key management is a separate process. Define who generates, stores, rotates and revokes keystore and truststore material, and how those activities are logged. Confirm with your security team how the regulation's key lifecycle items apply to your environment before you configure anything.
Article 21(2)(d) and the supply chain policy in the Implementing Regulation shift attention to the supplier relationship. Supplier selection and contracts must address cybersecurity requirements, incident notification, audit rights, subcontracting and exit. A NiFi flow that sends data to a supplier is one place where those obligations become technical. Document each supplier endpoint, the authentication method used, the certificate authority that issued its certificate and the owner who approves changes to that flow. Because NiFi 1.x is no longer maintained and NiFi 2 changed how flows are stored, confirm your platform version before building evidence on it. The NiFi download page lists current releases and support status.
Mapping NIS2 and Implementing Regulation 2024/2690 requirements to NiFi configuration
This table maps each NIS2 and Implementing Regulation 2024/2690 requirement in scope to the NiFi capability or configuration that addresses it, and marks whether the platform supports the control or whether it stays an organizational policy. Read the platform-supported rows as the settings your team must configure and evidence, and the policy-only rows as decisions your organization documents outside NiFi. Note that NIS2 creates no certificate of compliance, so the table lists what an assessor is likely to ask to see.
| Requirement | NiFi capability or configuration | Platform-supported or policy only |
|---|---|---|
| Article 21(2)(h): policies on cryptography and encryption | No NiFi feature provides this policy. Record approved protocols and cipher settings in your cryptography policy and reference the NiFi configuration that implements them. | Policy only |
| Annex 9.2(a): cryptography type and strength by asset classification | Set TLS on every site-to-site and listener connection, and apply stronger protection to flows carrying higher-classified data. Document which flows are classified and how each is protected. | Platform-supported with policy input |
| Annex 9.2(b): approved protocols, algorithms and agility | Configure TLS protocol versions and cipher suites on NiFi HTTPS, cluster and site-to-site endpoints. Confirm the supported settings for your NiFi release before fixing them in policy. | Platform-supported with policy input |
| Annex 9.2(c): key management lifecycle | NiFi keystores, truststores and sensitive parameter keys need documented generation, distribution, rotation, revocation and backup. NiFi does not manage this lifecycle for you, so use your key management process. | Policy only |
| Article 21(2)(d) and Article 21(3): supplier security relationship | Assess each supplier of NiFi components, such as custom processor bundles, registry clients and external services. NiFi is open source under Apache-2.0, so supplier review covers your integrators and hosting providers. | Policy only |
| Annex 5.1.2: supplier selection and lock-in | Record how flows are exported and versioned so they can run on another platform. Flow definitions in a registry client and documented parameters reduce dependence on one integrator. | Policy only |
| Annex 5.1.4: contract clauses on audit, incidents and exit | Contracts with integrators should cover audit rights, vulnerability handling and exit. Require delivery of flow definitions, configuration and keys handling in the contract. | Policy only |
| Authentication and access to flows | Use LDAP, OpenID Connect, SAML 2.0 or X.509 client certificates. The Kerberos provider is deprecated, so avoid it in new builds. | Platform-supported |
| Network exposure of the UI | Without a security configuration, NiFi binds to 127.0.0.1. Keep that default until TLS and an authentication provider are configured, then document the bind address and listening ports. | Platform-supported |
| Versioned flow changes | Flow Registry Clients for GitHub and GitLab store flow versions in Git. Use them with review steps so each change to a supplier-facing flow has an approval record. | Platform-supported with process |
How NiFi secures a supplier exchange hop by hop
A supplier exchange passes through several trust boundaries, and each one needs its own TLS and authentication decision. The first is the NiFi UI and API, which the administration guide documents as binding to 127.0.0.1 when no security configuration is provided, so the first hardening step is deliberate HTTPS configuration with a certificate your team controls and an authentication provider chosen from the documented set: single-user, LDAP, OpenID Connect, SAML 2.0 or X.509 client certificates. The Kerberos provider is deprecated, so do not design new access around it. The second boundary is cluster node communication and the coordination layer (embedded or external ZooKeeper, or Kubernetes state through ConfigMaps or Leases), where node-to-node traffic and state stores must be encrypted and authenticated according to the cluster settings in your version.
The third boundary is site-to-site, which carries data between NiFi instances or into a supplier-facing NiFi. Use secure site-to-site with mutual certificate authentication, and record which remote instance is trusted for each Remote Process Group. The fourth boundary is the processors that call external supplier endpoints, such as SFTP or HTTPS APIs. Each processor exposes its own TLS and host key options, and these differ between processor bundles and between NiFi 1.x and 2.x. For every supplier-facing processor, confirm in your version which protocol versions and cipher suites it negotiates, whether it verifies the supplier's host key or certificate chain, and whether a trust store can be scoped to that supplier alone. Treat any option that disables verification as a documented exception with an owner and an expiry date.
The credentials for these hops belong in the key policy, not in flow definitions. Put supplier passwords, private keys, API tokens and keystore passwords in sensitive parameters or a parameter provider, and reference them from controller services, because flow JSON and Git-versioned flows are readable by anyone with repository access. Your cryptography policy should list each controller service that holds key material, who may change it, how it is rotated, and how a compromised supplier key is revoked. Ask your integrator to show, for one supplier flow, where every private key and secret is stored, which role can read it, and how a change to it appears in your logs.
What evidence NiFi produces for a NIS2 assessor
A NIS2 assessor will test whether the cryptography and supplier controls described in policy are the ones the platform actually runs. The six items below connect the written policy to configuration, flow history, data movement records and certificate state, so each claim can be traced to a retained artifact.
Flow definitions in Git
Exported flow definitions are the record of what NiFi is configured to move, how it encrypts it and which endpoints it trusts. When flows are versioned through a Flow Registry Client, each change should carry a commit, a reviewer and an approval. Ask the assessor's question directly: can you show who changed the TLS-enabled processor for a supplier endpoint, when, and who approved it? Confirm which Git host your organization will use and how long its history and branch protection rules are retained.
Provenance records of data movement
Provenance records show each data event as it moves through a flow, including receipt from a supplier, transformation and delivery. For Article 21(2)(d), these records help show what was exchanged with which supplier and whether the transfer completed. Confirm the provenance retention settings and where the repository sits, because records that expire before an assessment window cannot support a finding. Restrict read access to provenance, since event content can expose the data itself.
Bulletin and log output
Bulletins flag processor and controller failures, such as a rejected certificate or a failed handshake with a supplier endpoint. Application and bootstrap logs keep a longer narrative of startup, authentication and configuration events. Assessors look for evidence that cryptographic failures are detected and routed to people who act on them. Confirm that log forwarding to your central log platform is configured and that log retention matches the period your incident and supervision records require.
Authorization policy exports
Authorization policies define who can view, modify or operate flows, controller services and sensitive parameters. Exporting them gives the assessor a point-in-time view of access to encryption keys, keystores and supplier credentials. Test that the export matches the access model in your identity provider, and that privileged roles are limited to named people. Record each export with a date and the approving owner so that later changes can be compared against it.
TLS and certificate inventories
A certificate inventory lists every keystore, truststore and certificate used by NiFi nodes, the Registry and supplier connections, with issuer, subject, algorithm, validity dates and owner. It is the evidence that key lifecycle controls, including renewal, revocation and destruction, are followed in practice. Compare the inventory against the TLS settings in the NiFi configuration files. Confirm the certificate authority, the renewal process and who receives expiry alerts.
Written cryptography and key policy
The cryptography policy sets approved protocols, algorithms, cipher strength and usage practices for data at rest and in transit, as Implementing Regulation 2024/2690 requires. The assessor will test whether NiFi settings match that policy, not whether the document exists. Map each approved protocol and algorithm to a NiFi configuration key, then record exceptions and their approvals. Confirm which function owns the policy and how often it is reviewed.
Who manages keys for NiFi flows and suppliers
The NiFi team operates the cryptographic material inside the platform: the keystore that holds each node's private key and certificate, the truststore that defines which peer and client certificates NiFi accepts, the sensitive properties key that protects encrypted values in flow configuration, and parameter contexts that carry credentials and certificate paths into components. These items are configured by people who edit flows, so the team must control who can change them and how they reach each environment. NiFi does not decide which algorithms or key lengths the entity approves. It only applies what the platform team sets.
- Keystore and truststore inventory: Record each keystore and truststore file, its owner, the nodes that use it, its certificate authority and its expiry date.
- Sensitive properties key: Document where the key is stored, who can read it, how it is backed up and how a change is planned, because a lost key makes encrypted values unrecoverable.
- Parameter context ownership: Keep a register of which parameter contexts hold passwords, keys or certificate paths, and restrict who can view sensitive parameters.
- Change records: Tie every certificate or key replacement to a versioned change, so the flow history shows when each cryptographic setting changed.
- Separation of duties: Confirm that developers cannot place production key material into parameter contexts without an approved change.
Ask the platform team to show the current keystore inventory and the process for replacing a node certificate without stopping the cluster, and confirm which of these steps NiFi itself records and which need a manual register.
The security team owns the key lifecycle policy. Point 9.2(c) of Implementing Regulation 2024/2690 lists the stages that key management must cover where appropriate: generation, certificates, distribution, storage, changing, compromise, revocation, recovery, backup, destruction, logging, and activation and deactivation dates. NiFi stores and uses keys but does not run this lifecycle for you. The security team must decide the rules, approve each step and keep the evidence, often in a key management system or PKI tool that sits outside NiFi.
- Generation and certificate issuance: Define approved algorithms, key lengths and certificate profiles, and record who issued each certificate and from which authority.
- Rotation and revocation: Set a rotation schedule for node, client and supplier certificates, and a revocation procedure for a suspected compromise, including how the truststore is updated.
- Activation and deactivation dates: Record when each key becomes active and when it must be retired, so every change can be matched to a date.
- Destruction logging: Keep a log of retired keys and certificates, including the date, the approver and confirmation that copies in backups and parameter contexts were removed.
- Recovery and backup: Document how the sensitive properties key and keystores are backed up, who can restore them and how recovery is tested.
NIS2 creates no certificate of compliance, so the lifecycle records are what an inspector will request. Confirm which lifecycle events your key management tooling logs automatically and which must be added to a manual register.
Suppliers that send data to your NiFi flows or receive data from them usually hold their own certificates, keys and endpoints. Article 21(2)(d) and the supplier points in Implementing Regulation 2024/2690 require you to consider each direct supplier's security practices, and the contract is the place to set what they must provide and disclose. Your NiFi cluster can only trust the certificates you admit to the truststore, so supplier certificate handling directly affects your own key lifecycle.
- Certificate details: Require each supplier to provide the certificate chain, issuing authority, expiry date and the endpoints it uses before you add it to the truststore.
- Rotation and compromise notice: Set a contractual duty to notify you promptly of a key compromise or certificate change, so you can revoke trust without delay.
- Subcontracting disclosure: Require disclosure of any third party that holds the supplier's keys or terminates its TLS connections.
- Audit rights: Include a right to audit or receive audit reports on how the supplier protects its keys, as the contract requirements in the Implementing Regulation call for where appropriate.
- Exit obligations: Specify how the supplier stops using a certificate and how trust is removed on both sides at contract end.
Before signing, ask each supplier for its key handling summary and check that its notification duties match the time you need to revoke a truststore entry.
What NiFi does not cover for NIS2
NiFi moves and protects data in transit, but NIS2 Article 21(2)(h) and 21(2)(d) also expect written policies, key lifecycle controls, supplier governance and evidence that sit outside the product. The cards below separate what your organization must still build from what the platform itself has changed or deprecated.
Cryptography policy and algorithm approval
NiFi offers TLS and encryption settings, but it does not decide which protocols, algorithms and cipher strengths your entity approves. Implementing Regulation 2024/2690 expects a policy that sets these by asset classification for data at rest and in transit, including cryptographic agility where appropriate. Write that policy first, then check each flow's TLS settings and processor encryption options against it, and record any exceptions.
Enterprise key lifecycle and HSM
NiFi's sensitive property and keystore handling does not give you enterprise key generation, rotation, revocation, backup, destruction or activation dates. Point 9.2(c) of the implementing regulation lists these areas, and logging of key events is part of the expectation. Confirm with your security team where keys and certificates are stored, whether a hardware security module or central key manager is in scope, and who approves each change.
Supplier risk assessment and contract clauses
NiFi is open source, so there is no vendor contract to negotiate with the project. Your obligations under Article 21(2)(d) still apply to the suppliers whose endpoints your flows reach, including their secure development practices and vulnerability history. Point 5.1.4 of the implementing regulation covers incident notification, audit rights, subcontracting and exit terms, and none of these are created by NiFi itself.
Supplier incident notification workflow
NiFi bulletins and provenance show what happened inside your flows, but they do not notify a supplier or receive notice from one. Define who your supplier contacts are, how a compromised supplier endpoint triggers a flow pause or certificate revocation, and how that event reaches your reporting process under Article 23. Test the path with a tabletop exercise before you rely on it.
NiFi Registry deprecation and Kerberos
NiFi Registry is deprecated and planned for removal in NiFi 3.0, so flow version control built on it needs a migration plan toward the Git-based Flow Registry Clients. The Kerberos authentication provider is also deprecated, so do not design new access models around it. Choose LDAP, OpenID Connect, SAML 2.0 or X.509 client certificates and document that choice as part of your access control evidence.
1.x end of support and 2.x migration
NiFi 1.28.1 reached its end-of-support date on December 8, 2024, and the project states that 1.x cannot be maintained further. Moving to 2.x requires upgrading to NiFi 1.27.0 first, then changing the flow configuration file from flow.xml.gz to flow.json.gz. The variable registry expression language scope is replaced by an ENVIRONMENT scope, so review every flow that depends on it before cutover.
Configuration sequence for a compliant NiFi exchange
This sequence turns a NiFi deployment into an exchange you can explain to an assessor: data is classified and protected under an approved cryptography and key policy, the platform is locked down, flows are changed through review, and the supplier hop is tested before anything carries live data.
Classify flows by data class
Before any processor is placed, list each supplier exchange and assign it a data class based on your asset classification, including whether it carries personal data or regulated records. The security, compliance and data owners sign the list, and each flow is tagged with the data class and the supplier it reaches. The output is a flow inventory that the cryptography policy can refer to, so every later control has a clear target.
Approve the cryptography and key policy
Set the approved protocols, algorithms, cipher strength and usage rules for data at rest and in transit, mapped to the data classes from the previous step, as Implementing Regulation 2024/2690 expects. The key policy must cover generation, certificate issuance, distribution, storage, rotation, compromise, revocation, recovery, backup, destruction and logging for every NiFi keystore, truststore and supplier certificate. Done means an approved, dated policy that names an owner for each key type.
Deploy NiFi 2 on Java 21 with TLS
Install NiFi 2 on the Java 21 runtime named in the NiFi administration guide, and configure HTTPS for the UI and cluster traffic, with certificates issued under the key policy. Select one authentication provider from those NiFi supports (single-user, LDAP, OpenID Connect, SAML 2.0 or X.509 client certificates) and avoid the deprecated Kerberos provider. Check that every listener negotiates only approved protocols and that the certificate chain validates against your truststore.
Lock the bind address and authorization policies
Confirm the bind address and listening interfaces match your network design, rather than relying on the loopback default that applies when no security configuration is supplied. Grant access through NiFi's policies to the smallest set of users and groups, separating flow designers, operators and read-only auditors. The check is an access review export showing each policy, the approver and the date, along with a test that an unauthorized account cannot open or modify a flow.
Store secrets in sensitive parameters
Move supplier credentials, API tokens, passwords and private key references out of processor properties and into sensitive parameters, or into a secrets store your organization has approved. Restrict which parameter contexts a flow can use, and make sure the sensitive values are not exported with flow definitions committed to version control. The output is a list of every sensitive value, its storage location and its rotation owner, which feeds the key policy's logging and rotation rules.
Version flows through a registry client
Connect the process group to a Flow Registry Client, such as the GitHub or GitLab clients NiFi 2 provides, so each flow version is committed to a repository. Require a reviewed pull request for every change to a supplier flow, and record who approved it and which version reached production. Confirm that a production instance can only run versions that came through that review path, and keep the repository permissions as strict as the NiFi policies.
Enable provenance and bulletin retention
Set provenance and bulletin retention so that every supplier hop leaves a record of what was sent, received and changed, with retention settings that match the audit requirements in your policy. Route bulletins to your monitoring and log platform, and restrict who can query provenance data, since it can include content references. The check is a sample transfer that you trace end to end in provenance and find again in your central logs.
Test the supplier hop before go-live
Before the flow carries live data, run a controlled test across the supplier connection that confirms the negotiated protocol, certificate validation, failure behavior when a certificate is invalid or expired, and the provenance trail for the transfer. Record the results, include the supplier's contract requirements for incident notification and exit, and get sign-off from the owner of the cryptography policy. The output is a dated test record that becomes evidence for the go-live decision.
Why NiFi version choice affects your NIS2 position
The NiFi version you run is a compliance decision, not only a technical one. The NiFi downloads page states that NiFi 1.28 is the last minor release of the version 1 series and that 1.28.1 reached end of support on December 8, 2024. The project explains that the 1.x line cannot be maintained further because it depends on Jetty 9.4, Spring Framework 5.3 and AngularJS 1.8, and none of these can be upgraded within that line. For an essential or important entity, a cryptography policy under Implementing Regulation 2024/2690 and supplier controls under Article 21(2)(d) both assume that the platform moving supplier data still receives security fixes. A flow platform on an unsupported line produces weak patch evidence and an awkward answer when an inspector asks which versions protect encrypted exchanges.
Moving to supported releases is scoped work. The migration guidance requires upgrading to NiFi 1.27.0 before moving to 2.0.0, and it changes the flow configuration file from flow.xml.gz to flow.json.gz. Scope these steps separately: the 1.27.0 stepping stone, the 2.x target release, the configuration file conversion, and a review of every flow for variable registry expression language use and renamed distributed map cache components, which the guidance lists as 2.0 changes. Each step needs a rollback point and a record of the TLS, authentication and certificate settings carried across, since these settings underpin the cryptography evidence discussed elsewhere on this page.
Before planning, confirm the current release and support window on the Apache NiFi download page. Ask your vendor or implementation partner to state which release line they will target, how long each line receives security fixes, and when your own patch cycle must move to the next one. Record the answers in your cryptography and supplier policies so that the version in production matches the version your evidence describes.
Questions buyers ask about NiFi, NIS2 and outside help
Does running Apache NiFi make us NIS2 compliant?
No. NIS2 is a directive, so obligations reach your organization through your national transposition law, and it creates no certificate of compliance. NiFi is one component you can use to meet parts of Article 21(2)(h) and Article 21(2)(d), mainly by enforcing TLS on every hop, controlling who can change flows and recording provenance. The remaining work sits in your policies: a cryptography policy that sets approved protocols and key management steps, a supply chain security policy with supplier criteria, and contracts that cover incident notification, audit rights and exit obligations. Authorities assess that evidence through inspections and information requests, so the flows only count when the policies and records around them are in place.
What does outside help cost, and what drives the effort?
No supplied fact gives a price or effort figure for this work, so DeployOpen does not state one here. Cost is driven by the amount of work in your written scope: the number of flows that carry supplier or sensitive data, the number of suppliers and endpoints each flow touches, how many key systems and certificate authorities must be integrated, whether flows must move from NiFi 1.x to 2.x first, and how far the evidence must reach (policy drafting, flow documentation, key logs or a full supplier review). Ask for a fixed-scope quote that lists each deliverable, what you provide, what is one-time (design, build, documentation) and what recurs (retainers for upgrades, testing and reviews). Compare quotes on the same listed scope, not on headline totals.
How long does scoping take, and what must we provide?
No supplied fact gives a duration for scoping, so confirm the timeline in the written scope rather than relying on a general estimate. Scoping usually depends on how quickly you can supply the inputs: an inventory of data flows that cross your boundary, the list of direct suppliers and service providers, your current cryptography and key management practices, certificate and key lifecycle records, the current NiFi version and cluster layout, and access to the systems where flows run. Expect the scope to be fixed only after those inputs are reviewed and any gaps are named. Ask for the assumptions list in writing, because missing inputs are the most common reason an engagement changes after it starts.
Can our own team build and run this internally?
Often yes, if you already have engineers who run NiFi and staff who own policy and supplier management. NiFi is Apache-2.0 licensed with no paid edition from the project, so the software cost is not the constraint. The harder parts are internal: writing a cryptography policy that meets the Annex points on approved algorithms and key lifecycle, running a supplier review, keeping evidence current, and keeping flow changes under review. Check whether your team can cover key generation, certificate distribution, rotation and revocation logging, and whether anyone can independently test the controls. If one of those is missing, a partner can fill the gap for a defined part of the work while your team keeps ownership of the policies.
Will our NIS2 obligations change after the national law and COM(2026) 13?
They may. Each Member State sets its own transposition law, and Article 5 allows national rules that give a higher level of cybersecurity, so your national authority's requirements can go beyond the EU text. The Commission proposed targeted amendments to NIS2 on 20 January 2026 (COM(2026) 13), including a new small mid-cap category. That proposal still needs approval by the European Parliament and the Council, and Commission pages updated through July 2026 describe it as a proposal. Confirm your entity classification and the rules your national authority applies, and plan the cryptography and supplier policies so they can be revised without rebuilding the flows.
Which NiFi version should we use for supplier data exchange?
Plan for NiFi 2. The NiFi downloads page states that NiFi 1.28 is the last minor release of the 1.x series, lists an end-of-support date of December 8, 2024 for 1.28.1, and strongly encourages users to upgrade to NiFi 2. The NiFi project explains that 1.x cannot be maintained further because it depends on Jetty 9.4, Spring Framework 5.3 and AngularJS 1.8. Migration requires upgrading to NiFi 1.27.0 before moving to 2.0.0 and changing the flow configuration file from flow.xml.gz to flow.json.gz. Confirm the current release on the NiFi downloads page before you set the target version, since the project publishes new releases regularly.
What should we ask a partner to show before signing?
Ask for a written scope that names each flow, each supplier endpoint, each key system and each evidence item, with the deliverables and acceptance criteria for each. Ask how the partner will map work to Article 21(2)(h) and Article 21(2)(d), and to the Implementing Regulation 2024/2690 points on cryptography and supply chain policy, without claiming that the work produces a certification. Ask who writes and who approves the policies, how key handling is logged, what happens to the flow configuration after handover, and what recurs under a retainer. DeployOpen plans, implements, hardens and documents self-hosted platforms in your infrastructure and prepares evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or attestation.
What changes for your team after the NiFi work is in place
Once the NiFi work is in place, the cryptography and supplier evidence becomes a standing operating duty, not a project deliverable. The most important recurring task is reviewing every flow change before it reaches production. Each pull request that alters a flow should be checked for TLS on every hop, the approved cipher suites and protocols in the cryptography policy, the parameter contexts that hold keys and credentials, and the supplier endpoints it touches. Your team also owns the key calendar: rotating the keystore, truststore and sensitive-parameter keys on the schedule your cryptography policy sets, and recording each rotation with its activation and deactivation dates, which Implementing Regulation 2024/2690 expects under point 9.2(c). Confirm with your own security team how the NiFi sensitive properties key and the node certificates are rotated, since the rotation steps depend on your deployment.
Supplier duties sit alongside the technical ones. Someone must review each direct supplier's audit reports, security attestations and incident notices on the cycle your contracts define, and update the supplier record when a finding affects a flow that carries their data. Patching is part of the same routine. NiFi 1.x can no longer be maintained, so the upgrade to the 2.x line, and then routine 2.x patch releases, should be tracked against the dates on the NiFi downloads page rather than left to ad hoc decisions. Review provenance samples on a set cadence to confirm that the records show the transfers you documented and no unexpected destinations.
Keep all of this evidence current at all times. Under Articles 32 to 34 of NIS2, a national competent authority can inspect your organization, run security audits or scans, and send information requests, and NIS2 creates no certificate that lets you point to a single approval. Your answer will be the flow register, the change approvals, the key logs, the supplier reviews and the provenance samples as they stand that week. Ask your national authority, or your legal adviser, which transposition law applies to your entity and what it requires you to keep and for how long.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including NiFi flows that carry regulated data. For NIS2 cryptography and supplier data exchange, we start from your cryptography policy and supplier register, then configure NiFi to meet them and hand over the evidence your team needs.
How we scope
- We inventory the NiFi flows that move data to and from direct suppliers and list each hop, protocol and data classification.
- We map each hop to the cryptography policy you hold or will write, including approved protocols, cipher strength and key lifecycle ownership.
- We agree the scope in writing before work starts, naming the flows, NiFi clusters, identity providers and supplier connections covered.
How we build
- We configure TLS on every NiFi hop, client and cluster connection, with certificate sources, trust stores and rotation settings documented.
- We set up sensitive parameter handling and key storage for supplier credentials, then confirm the keys and certificates follow your key management rules.
- We test each supplier exchange for encryption in transit, failed-handshake behavior and provenance records, and document the results.
How we hand over
- We deliver the written configuration baseline, including TLS settings, cipher choices, key and certificate inventory and rotation procedures.
- We provide a supplier exchange register that links each flow to its supplier, data class, encryption method and responsible owner.
- We walk your operations and security teams through the evidence trail, so they can answer audit requests without DeployOpen involved.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, covering certificate renewals and changes to supplier connections.
- We re-test affected flows after NiFi upgrades, including planned moves from 1.x to 2.x, before changes reach production.
- Assessment of your compliance position remains with your auditors and competent authority, since DeployOpen prepares controls and evidence but issues no certification.
