How Apache Kafka supports NIS2 Article 21 measures for your entity
If your organization is an essential or important entity under NIS2 and runs Kafka, you need to show a national authority how your Article 21 measures work in practice. NIS2 creates no certificate of compliance. Authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines, so the evidence you hand over is what matters. Kafka covers only the technical configuration layer: cryptography in transit, activity logging and monitoring, and replication for redundancy. Those map to Article 21(2)(h) on cryptography and encryption, and to points 3.2 and 4.2 of the Annex to Implementing Regulation (EU) 2024/2690 on monitoring and logging and on backups and redundancy. The regulation text is available on EUR-Lex, and it should be your starting point for mapping each setting to a requirement.
Kafka does not cover the rest of the obligations. Risk analysis, security policies, supplier management, human resources security, training, incident handling procedures, business continuity governance and the 24-hour, 72-hour and one-month reporting duties under Article 23 are organizational work that sits outside any broker configuration. Kafka also does not encrypt data at rest on its own, since in KRaft mode sensitive values in metadata records are stored unencrypted, so disk, volume or application-level encryption must be documented separately. Confirm with your national competent authority how it expects these items to be evidenced, and confirm which sector annex and national transposition law apply to your entity, because Member States may set stricter rules under Article 5.
Start by inventorying which topics carry data in scope and which clusters host them, then decide per cluster whether unsecured listeners can be removed, whether TLS is enforced on every broker and client listener, and whether authorization is backed by ACLs rather than an open default. Next, define what your logs must show, such as authentication failures and ACL changes, and where they are shipped and retained. Finally, decide how replication and backups are sized for the topics that matter most and test recovery, because an authority will ask for evidence that the design works, not only that it exists. Verify each Kafka setting against the version you run, using the Apache Kafka 4.3 security overview as the reference.
Mapping NIS2 requirements to Kafka settings
This table maps three NIS2 implementing requirements to the Kafka capability that supports each one, the configuration to set, and what remains with the surrounding platform. Read each row as a starting checklist for your own architecture, then confirm details against your cluster version and national transposition law.
| Requirement | Kafka capability | Configuration and gaps |
|---|---|---|
| Article 21(2)(h): policies on cryptography and, where appropriate, encryption | SSL/TLS encrypts traffic between clients, brokers and tools. SASL mechanisms (GSSAPI, PLAIN, SCRAM-SHA-256, SCRAM-SHA-512, OAUTHBEARER) authenticate them. | Define SSL-only or SASL_SSL listeners and disable unsecured listeners. Document the cipher and certificate policy. KRaft stores sensitive metadata unencrypted, so add disk, volume or application-level encryption. |
| Access control supporting cryptography policy (Article 21(2)(i) context) | StandardAuthorizer stores ACLs in the cluster metadata log. Resources without ACLs are restricted to super users by default. | Set allow.everyone.if.no.acl.found to false and keep super users to a small named set. Confirm the authorizer and ACL export procedure for your version. |
| Point 3.2: procedures and tools to monitor and log activity | Kafka provides authorization decisions and broker and client activity that can feed external monitoring. Kafka does not itself run detection rules. | Ship broker, controller and authorizer logs to a central system. Alert on authentication failures, ACL changes and listener changes. Assign owners and review cadence in your procedures. |
| Point 4.2: backup copies of data and redundancy | MirrorMaker 2 replicates topics with configuration, consumer group offsets and ACLs to another cluster, preserving partitioning. | Plan a second cluster in a separate failure domain and test failover. Replication is not a backup: keep independent copies and restore tests. Confirm recovery objectives with the business. |
Evidence auditors and authorities can ask for
Assessors and supervisory authorities usually ask how a control works and how you know it still works. The records below show Kafka's configuration, access and resilience over time. Each one needs a named owner and a refresh routine, and none of them is a compliance finding on its own.
Listener and TLS configuration export
Export the effective listener map from the running brokers, including each listener's protocol, the TLS versions and cipher settings in use, and the client authentication mode. Kafka security is optional, so any plaintext listener still open is the first item an assessor will check. Platform engineering runs the export after each configuration change and archives it with the date and cluster ID. Security reviews each diff against the approved baseline.
ACL listings from the metadata log
In KRaft clusters the StandardAuthorizer stores ACLs in the metadata log, so the listing should be exported from the cluster itself. Include the super user list and the value of allow.everyone.if.no.acl.found, because resources without ACLs are limited to super users unless that setting is true. The data platform team issues the export at each access review, and each data owner confirms the principals assigned to their topics and groups.
MirrorMaker 2 configuration and lag records
Keep the MirrorMaker 2 configuration, including source and target cluster aliases and topic and group filters, under version control. Lag records with timestamps show whether mirrored topics, consumer group offsets and ACLs are arriving at the other site. Platform engineering owns the configuration and the lag samples. The business owner of each replicated topic confirms that the data is approved to leave the primary site.
Backup and restore test records
Replication across brokers or sites does not protect against deletion, corruption or a faulty configuration change that spreads to every copy. Keep backup job logs, the scope of each backup (topic configuration, metadata and data), and restore test results showing the topics restored, the checks passed and the time taken. Operations owns the test schedule. The application owner signs off that the restored data is complete.
Kafka version upgrade change records
Record each Kafka version change with the source and target release, the release notes reviewed, the rolling upgrade order and the point at which you would roll back. Rolling upgrades are supported from the last three releases to the latest version, so the record should show that the starting version falls in that range. The project lists 4.3.1, 4.2.2 and 4.1.2 as supported. The change manager owns the record, and platform engineering attaches the test results.
Configuration sequence for NIS2-aligned Kafka
This sequence takes a self-hosted Kafka cluster from a confirmed supported release to a configuration that supports the encryption, monitoring and redundancy measures in NIS2 Article 21. Each step produces a named artifact that your compliance and security reviewers can inspect.
Confirm the supported release and upgrade path
The platform team checks the Kafka downloads page to confirm which 4.x release is currently supported, and reads the upgrade notes for the starting version. Clusters still running ZooKeeper must migrate to KRaft before moving to 4.x, and KRaft clusters older than 3.3.x should first move to 3.9.x. Confirm the Java runtime for brokers and Kafka Connect as well. The output is a written version baseline and upgrade plan, approved by the owner of the platform, so that patching can be shown as a managed process rather than an ad hoc activity.
Enforce TLS on every listener
Security in Kafka is optional, so every broker listener, controller listener and inter-broker listener must be set to a secured protocol, and plaintext listeners must be removed rather than left available for legacy clients. Engineers issue certificates from the organization's internal certificate authority, configure keystores and truststores, and verify that clients connect over TLS. The output is a listener configuration file and a test run in which a plaintext connection attempt is refused. Cryptography policy referenced by Article 21(2)(h) should name this configuration as the implementation.
Select a SASL mechanism and authorization model
Choose one SASL mechanism for client and tool authentication from the documented options, such as SCRAM-SHA-512 or OAUTHBEARER, based on your identity infrastructure. Then configure the StandardAuthorizer so that ACLs are stored in the KRaft metadata log, and keep allow.everyone.if.no.acl.found at its default so that resources without an explicit grant remain limited to super users. Keep the super user list short and documented. The output is an authentication and authorization design record, a set of ACL definitions per service principal, and a test showing that an unlisted principal is denied access to a sample topic.
Forward broker and authorizer logs to a monitored store
Configure broker and controller logging, including authorizer decisions, so that authentication failures, ACL denials and configuration changes are written to a file or stream that your log platform collects. Route these events to a central store with access restricted to the security team and set alert rules for repeated denials and unexpected administrative actions. Confirm that the alerts reach a person or queue that is staffed. The output is a documented log source list, a working alert rule, and a record of one test event traced from the broker to the monitoring dashboard.
Configure encryption at rest below the application
Kafka does not encrypt sensitive records in KRaft metadata, so protection of data at rest must come from the disk, volume or application layer that you control. Platform engineers enable full-disk or volume encryption on broker and controller data directories, store keys in a managed key service, and document key rotation and access. Where topics carry particularly sensitive payloads, the team should also evaluate application-level encryption. The output is a storage encryption specification and a verification record showing that the data directories are encrypted on each node.
Set up MirrorMaker 2 and test restoration
Deploy MirrorMaker 2 on Kafka Connect to replicate topics, their configuration, consumer group offsets and ACLs to a second cluster in a separate failure domain that you operate. Document the replication scope, including which topics are excluded, and the replication lag that operators will monitor. Then run a restore exercise in which the secondary cluster is promoted and consumers resume from replicated offsets. Record how long recovery took and what data was missing. The output is a replication configuration, a written restore procedure, and a signed test record that supports the backup and redundancy measures in point 4.2 of the Annex to Implementing Regulation 2024/2690.
Encryption and monitoring settings that matter in practice
The encryption and access settings interact, so they need to be designed together. Kafka's security is optional, and a cluster can run an unsecured listener next to a secured one, so the first control to verify is that every listener carrying client, broker or tool traffic uses SSL/TLS. Next, choose the SASL mechanism for each listener. The documented options are GSSAPI (Kerberos), PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER, and the choice determines where credentials are verified and how they are rotated. Authentication only establishes identity. The StandardAuthorizer in KRaft mode stores ACLs in the metadata log, and a resource with no ACL is restricted to super users unless allow.everyone.if.no.acl.found is set to true. Confirm that this key is absent or false in every broker configuration, because a cluster that accepts authenticated clients on open topics has an access model that no one reviewed.
That default matters for the audit trail. If allow.everyone.if.no.acl.found is enabled, a topic created without an explicit ACL is readable and writable by any authenticated principal, and the authorization decision no longer reflects a deliberate grant. Ask the platform team to export the ACL list from the metadata and reconcile it against the topic inventory, then record who approved each grant. Also confirm whether authorization decisions are logged on your brokers and at what level, since that setting is local to your deployment and should be verified against the version you run, not assumed from the defaults.
Kafka's own logs are not the monitoring procedure that point 3.2 of the Annex to Implementing Regulation 2024/2690 requires. Broker and controller logs record the cluster's operation, but they do not, by themselves, detect events that could be incidents, and they do not show the reviewer what was done with the data. Plan a separate pipeline that collects broker, controller, authentication and authorization events, correlates them with network and host telemetry, and raises alerts on failed authentication, new principals, ACL changes and unexpected listener use. Automate detection where feasible, and document who responds to each alert. Treat the monitoring design as an open decision for your security team to confirm against the current ENISA technical implementation guidance.
Redundancy options for your environment
Within one site, Kafka protects availability through partition replication across brokers. Each partition has a leader and followers, and the replication factor and minimum in-sync replicas settings decide how many broker failures a topic can absorb before producers are refused writes. Replication inside the cluster copies the log and, because the metadata log is replicated across KRaft controllers, the cluster configuration. It does not protect against the loss of the site, a shared power or network failure, or an operator error that deletes a topic, because those changes replicate too.
- Replication factor and min ISR: Set per topic, with the trade-off between durability and write availability documented for each data class.
- Rack or zone placement: Spread brokers and controllers across failure domains so one rack loss does not remove a quorum.
- Controller quorum: Keep an odd number of controllers on separate hosts.
- Facilities and staff: Confirm power, cooling, network paths and on-call coverage for the single site, since replication cannot supply them.
- Off-cluster backups: Keep copies of topic data and configuration outside the cluster, with tested restores.
Confirm the replication settings and failure domains against your own risk assessment before going live.
MirrorMaker 2 is built on Kafka Connect and replicates topics with their configuration, consumer groups with offsets, and ACLs from a source cluster to a target cluster while preserving partitioning. That gives a second site a copy of the data and the access model, so consumers can resume there after an outage. Replication is asynchronous, so messages written to the source shortly before a failure may not yet exist at the target, and the recovery point depends on replication lag. Failover also needs a documented decision on who switches producers and consumers and when.
- Scope: Choose which topics, groups and ACL sets are mirrored, and exclude topics whose data may not leave a given site or jurisdiction.
- Lag monitoring: Alert on replication lag so the recovery point is known at all times.
- Offset translation: Test how consumers resume at the target and how offsets are checked after failover.
- Second-site capacity: Size the target cluster and its staff rota for production load, not only for standby.
- Failover runbook: Write, rehearse and assign the switchover steps, including return to the primary site.
Confirm the recovery point and recovery time your organization needs with the business owners and your risk assessment before choosing this layout.
Where the network is isolated or heavily restricted, replication to an external site may not be possible, and the design depends on local redundancy and controlled transfer of backups or software. Kafka's replication still works inside the isolated network, but updates, container images and recovery material must be brought in through an approved path. Because the platform cannot reach outside services, identity, certificates and monitoring must also run inside the enclave, which increases the number of components the team must keep alive.
- Local topology: Use replicated brokers across isolated hosts or racks as the primary redundancy layer.
- Offline backups: Store copies of topic data, configuration and TLS material on media or storage that the enclave controls, with restores tested inside the enclave.
- Software intake: Document how packages, images and patches are verified and imported, and who approves them.
- Local identity and certificates: Run the certificate authority and identity services inside the boundary so cluster authentication survives an outage.
- Staffing: Confirm that enough trained people can operate the cluster without outside access during an incident.
Confirm with your accreditation authority and your own risk assessment which restoration paths the restricted environment permits.
Questions buyers ask before hiring help with NIS2 Kafka controls
Does NIS2 certify a Kafka deployment?
No. NIS2 creates no certificate of compliance for a product or deployment. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. Your evidence is what you show those authorities: documented policies, configuration records, monitoring and logs, and tested backup and recovery. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Ask any partner who claims otherwise to show the legal basis for the claim.
Which national law applies to our NIS2 obligations?
NIS2 is a directive, so obligations reach your organization through the national law that transposes it in each Member State where you are established or provide services. Member States had to adopt and publish those measures by 17 October 2024 and apply them from 18 October 2024. Confirm with your national competent authority and legal counsel which transposition law applies, whether you are classed as essential or important, and whether your national rules add requirements beyond the directive. Implementing Regulation (EU) 2024/2690 sets the technical measures for the sectors it covers, so check whether it applies to your entity type.
What drives the effort of a NIS2 Kafka engagement?
The main drivers are the number of clusters, the sites they span, how identities are integrated, and how much of the log and monitoring pipeline must be built. Each extra cluster adds listener, certificate and ACL work. Cross-site replication with MirrorMaker 2 adds design and verification for each replicated topic and its ACLs. Identity integration with your directory or SSO and the handling of service accounts often takes more time than the broker settings themselves. A log pipeline that sends authorization and audit events to a central store adds integration and retention design. Ask for a written scope that lists each of these items separately.
How long does this work take?
The duration depends on the written scope, so no fixed figure applies to every organization. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The schedule usually depends on how many clusters and sites are included, whether existing clusters need an upgrade to a supported 4.x release first, and how quickly your teams can review designs and approve change windows. Ask for milestones tied to deliverables, and ask which items depend on your approvals or on third parties such as identity or log platform owners.
What does our team need to provide during the engagement?
You need named owners, access and change windows. Assign an owner for each cluster, for the identity platform, for the log and monitoring stack and for the backup environment. Provide read and administrative access to the systems in scope through your own access controls, and make sure those accounts are recorded. Agree change windows for broker restarts, certificate rotation and any upgrade, because rolling changes still need capacity and a rollback plan. Decide early who approves designs and who accepts evidence, since those decisions set the pace of the work.
Can our internal team run these controls without outside help?
Yes, if the team has skills in KRaft operation, TLS and SASL configuration, ACL design, monitoring and backup testing. Kafka 4.x runs only in KRaft mode, and the Kafka documentation covers its security features, so a capable platform team can build the controls. The harder part is usually evidence and repeatability: keeping configuration under version control, testing restores on a schedule and producing records an assessor can follow. Many organizations choose a partner for the design review, the first build or an independent check, then operate the platform themselves. Assess your team's skills against the scope before deciding.
Which Kafka settings cover NIS2 encryption and logging, and which need other tools?
Kafka covers part of the work. It supports SSL/TLS between clients, brokers and tools, and SASL mechanisms such as SCRAM and Kerberos, and StandardAuthorizer stores ACLs in the metadata log. Security is optional, so you must enforce secured listeners and disable unsecured ones yourself. Kafka does not encrypt sensitive data stored in KRaft metadata records, so you need disk, volume or application-level encryption for data at rest. Monitoring, central log retention, offsite backup and restore testing sit in the surrounding platform. Confirm each gap against the specific Article 21 measure and the ENISA technical guidance before you build.
Keeping a supported Kafka release for audit purposes
Run only a Kafka release the project still supports. The Kafka downloads page lists 4.3.1, 4.2.2 and 4.1.2 as the supported releases, and the project makes bugfix releases only for those. Earlier versions are archived. For an NIS2 file, this matters because an auditor or national authority will ask whether the platform still receives security fixes. Record the version running in each environment, the date you checked it against the downloads page, and the patch level you applied. Confirm the current list on the official pages before you rely on it, since the project publishes new releases about every four months.
Plan upgrades as a sequence, not a jump. The time-based release plan says rolling upgrades are supported from each of the last three releases to the latest version. A cluster on an older line needs intermediate steps. Since Kafka 4.0, only KRaft mode is supported, so any ZooKeeper-based cluster must migrate to KRaft before it moves to 4.x. The upgrade notes also recommend that KRaft clusters older than 3.3.x first move to 3.9.x. Put each hop in your change records with its test evidence, because a documented upgrade path is easier to defend than an ad hoc one.
Check the runtime as well as the broker. Since Kafka 4.0, brokers, Kafka Connect and tools require Java 17, while clients and Kafka Streams applications need at least Java 11. Your JVM baseline belongs in the same inventory as the Kafka version, and it must be patched through your normal vulnerability process. Confirm these requirements against the upgrade notes for the exact release you choose, and ask your implementation partner to include the JVM and operating system in the upgrade test plan.
How DeployOpen scopes NIS2 Kafka configuration and evidence
DeployOpen plans, implements and hands over self-hosted Apache Kafka inside your own infrastructure, with the NIS2 Article 21 measures mapped to configuration, monitoring and backup decisions you can show a regulator. Engagements are fixed-scope, and the written scope defines which Kafka controls, platform components and evidence are covered.
How we scope
- Agree in writing which Article 21 measures and Kafka clusters are inside the engagement.
- Map TLS listeners, SASL mechanisms, ACL design and retention settings to each cluster and topic group.
- Identify which controls sit outside Kafka, such as disk encryption, log shipping and secrets storage, and assign owners.
How we build
- Deploy KRaft clusters with encrypted listeners, authenticated clients and authorization enabled from the first build.
- Configure broker and audit logging, metrics and alert rules so monitoring covers cluster activity and access changes.
- Set up MirrorMaker 2 replication, backup procedures and restore tests for topics, offsets and ACLs at the recovery targets you agree.
How we hand over
- Deliver configuration baselines, runbooks and an evidence register linking each control to the setting or log that proves it.
- Run verification tests, including negative tests for unencrypted connections and unauthorized topic access, and record results.
- Train your platform and security staff on day-two operations, change control for configuration, and retaining evidence.
How we support
- Support configuration reviews when Kafka releases, new topics or new connected systems change the scope.
- Plan upgrades within the supported Kafka 4.x releases, with versions and steps confirmed against the upgrade notes at the time.
- Offer ongoing support, upgrades and continuous testing as a retainer, priced from the written scope.
