Open source threat intelligence for NIS2 information sharing

Open source threat intelligence for NIS2 information sharing: what Article 29 asks

If you are an essential or important entity under NIS2, Article 29 makes exchanging cybersecurity information voluntary, but it does require you to notify your competent authority when you join an information-sharing arrangement and when your withdrawal takes effect. A self-hosted MISP or OpenCTI instance is the usual way to receive shared data, control how it is distributed and keep it inside your own environment. Your decision is less about whether to share and more about which communities you join, who inside the organization can see what arrives, and how the notification record is kept current. The article does not name a specific list of communities, so confirm with your national competent authority which notification format and channel it expects.

NIS2 creates no certificate of compliance. Competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines, so the evidence you produce is about process and records: the join and withdrawal notices, the sharing agreements or community rules you accepted, the access and distribution settings in your platform, and the log of what was received and acted on. Plan for those records from the first day, because they are what an assessor will ask to see. The Commission's proposal COM(2026) 13, which includes a new small mid-cap category, is still a proposal that needs approval by the European Parliament and the Council, so build your process against the current Directive and its national transposition law.

Before you configure anything, confirm three points with your legal and security leads: which national transposition law applies to your entity, which sharing arrangements are open to you, and whether any community requires notification or membership terms beyond Article 29. Then set your sharing rules in the platform itself, including distribution levels and sharing groups, so that a notice from a community cannot be pushed to parties that should not receive it. Keep the notification and withdrawal steps in a written runbook with named owners, so the record of membership stays accurate for supervisors even when people change roles.

Mapping NIS2 Article 29 duties to platform configuration

This table maps each relevant NIS2 provision to what the function must do and how MISP or OpenCTI can be configured to support it. Read each row as a requirement, the platform setting that serves it, and the item to confirm with your national authority. The main takeaway is that the sharing rules, membership notice and voluntary reporting record must be designed before the first indicator is shared.

Requirement	What the function must do	How to configure MISP or OpenCTI
Article 29(1) exchange types	Be able to exchange threats, near misses, vulnerabilities, indicators of compromise, adversarial tactics, threat actor information and detection recommendations	Use MISP event and attribute types and galaxies for threat actors and MITRE ATT&CK; in OpenCTI, use the STIX2-based schema and the ATT&CK connector
Article 29(2) community membership	Exchange only within a community of essential and important entities and, where relevant, their suppliers	Create sharing groups limited to community members; connect the instance to the community hub using synchronization
Distribution and sharing scope	Limit each indicator to the audience agreed in the arrangement's rules	Set distribution levels per event and per attribute; use custom sharing groups where a finer scope is needed
Synchronization with partners	Receive and send only the agreed material with each community member	Configure automatic synchronization with trusted instances and review sharing group membership on a fixed schedule
Article 29(4) membership notice	Notify the competent authority when joining an arrangement and when withdrawal takes effect	Keep a notification record in the platform's case or note fields or in your compliance system, with dates for join and withdrawal; confirm the form and channel with your national authority
Withdrawal handling	Stop sharing and remove community access when withdrawal takes effect	Remove the instance from sync and revoke sharing group access; confirm what must be retained or deleted from the record
Article 30 voluntary reporting	Notify incidents, threats and near misses voluntarily, without added obligations from the voluntary channel	Record voluntary submissions separately from mandatory incident reports so the two paths stay distinct in the audit trail
Transposition details	Apply the national law that implements the Directive, which may add rules	Confirm with your competent authority and national CSIRT which arrangement, forms and deadlines apply in your Member State

MISP or OpenCTI for a NIS2 sharing role

MISP is built around exchange. Its distribution levels and sharing groups control who sees each attribute, and its synchronization feature lets instances in a trusted community exchange events automatically. For an essential or important entity that wants to join a sharing arrangement under NIS2 Article 29, MISP is usually the first tool to evaluate, because the arrangement's members typically already publish and consume MISP events. The project's repository describes a license model that no single entity can change, and the project is associated with CIRCL, the Computer Incident Response Center Luxembourg. The software is licensed under AGPL-3.0, which matters if you modify it and offer it to users over a network.

Distribution and sharing groups: Set distribution per event and per attribute, and create sharing groups that match the arrangement's agreed audience.
Synchronization: Confirm with the community operator which sync pattern they use and which filters apply before you connect.
Export formats: MISP exports STIX 1 and 2, Suricata, Snort, Zeek and RPZ, which feeds detection without manual rewriting.
API and tooling: The OpenAPI-described API and the PyMISP library support automation into your SIEM and SOAR.
Licensing: Review AGPL-3.0 obligations with counsel if you alter the code, and note that taxonomies and galaxies carry separate CC0 or BSD terms.

Confirm with the arrangement which MISP version the community runs, since MISP 2.5 is the recommended line for new deployments and 2.4 is end of life.

Open source platforms that fit the NIS2 sharing workflow

NIS2 Article 29 sharing sits between a community exchange and your own detection and response. The platforms below cover each step: MISP or OpenCTI holds and distributes intelligence, Suricata and Zeek turn it into sensor rules, Wazuh or Security Onion watch your estate, and Shuffle moves enriched indicators into incident handling.

MISP as the sharing hub

MISP stores indicators, applies distribution levels and sharing groups, and synchronizes events with trusted communities. It is licensed under AGPL-3.0, and version 2.5.50 was published on October 10, 2026. Before you join a sharing arrangement, confirm which communities run MISP and which sharing formats and synchronization settings each one expects, since a community may not accept every export format.

OpenCTI as the knowledge layer

OpenCTI models intelligence on the STIX2 standards and exposes a GraphQL API, which suits teams that want to map campaigns, actors and ATT&CK techniques alongside shared indicators. The Community Edition is licensed under Apache 2.0, while the Enterprise Edition uses a separate proprietary license. Check which features your workflow needs before assuming the Community Edition covers them, and confirm which exchange format your community accepts.

Suricata and Zeek exports from MISP

MISP can export indicators as Suricata and Zeek rules, which lets shared intelligence reach network sensors without manual rule writing. Suricata is licensed under GPL-2.0 and Zeek under a BSD-style license. Confirm which rule format each sensor and each sharing partner expects, and decide who reviews exported rules before they reach production, because a bad indicator can generate false positives across the estate.

Wazuh or Security Onion for detection

Wazuh (GPL-2.0) and Security Onion (Elastic License 2.0) turn shared indicators into alerts across endpoints, logs and network traffic. Security Onion bundles Suricata, Zeek and the Elastic stack, while Wazuh focuses on host and log security with XDR and SIEM features. Check the license terms of the platform you choose against your reuse and redistribution needs, and confirm which indicator types each one can match on.

Shuffle for enrichment and handoff

Shuffle is a SOAR platform licensed under AGPL-3.0 that can enrich indicators, check them against your asset inventory and open tickets for incident response. This is where a shared indicator becomes an action. Define the enrichment steps, approval points and the fields passed to the case system, and confirm who is notified when a sharing partner withdraws or an indicator is revoked.

How shared intelligence feeds incident handling

Shared intelligence only helps incident handling once the team has a fixed path from an arriving event to a decision. In a self-hosted MISP instance, a new event from a sharing community lands with its distribution level and sharing group intact. The correlation engine then looks for matches against existing attributes, including exact values and patterns such as CIDR overlaps, so an analyst sees which of the team's own systems or past alerts the indicator touches. Triage follows: an analyst or curation rule decides whether each attribute is for detection, for reference only, or for discard. OpenCTI follows a similar path, but records the data as STIX2 objects in a knowledge graph, which helps when relationships between actors, campaigns and infrastructure matter more than individual values.

Indicators marked for action move into detection. MISP can export to Suricata, Snort, Zeek and RPZ formats, and to a SIEM or SOAR through its API, so the same triaged set can feed a network sensor and a log correlation rule. Before anything is pushed, the team should decide which tags and sharing levels permit automated blocking, since a false positive from a community feed can block a business service. Indicators that are only retained stay in the platform for later hunting or pattern matching, with a documented reason. Confirm with your SIEM and sensor vendors which export formats each consumer accepts, and test a rule set in a non-blocking mode first.

Incident notification is a separate decision. Under NIS2, Article 30 lets essential and important entities voluntarily notify incidents, cyber threats and near misses, and voluntary reporting imposes no additional obligations on the notifying entity. The mandatory reporting duties in Article 23 apply to significant incidents and are not triggered by a threat intelligence match alone. The playbook should therefore record, for each confirmed event, whether it meets the significance criteria in Commission Implementing Regulation (EU) 2024/2690 where that regulation applies to the entity, whether a national authority requires a report, and whether the team also wants to share voluntarily. Keeping these three outcomes separate in the case record is what makes the notification trail defensible later.

Evidence auditors and supervisors ask for

This table maps each piece of evidence a competent authority or assessor may ask for under NIS2 Article 29 to the component that produces it and the question it answers. Read it as a checklist for designing logs and records before the first sharing event, remembering that NIS2 issues no certificate of compliance, so supervisors judge the records you can produce during inspections and audits.

Evidence	Produced by	What it shows
Membership notification to the competent authority	Governance records kept by the compliance lead, dated against the arrangement's start	That the entity notified the authority when it joined an information-sharing arrangement, as Article 29(4) requires
Withdrawal record and effective date	Governance records, with MISP sharing group and user access removal logs	When withdrawal took effect and that access to shared data stopped on that date
Sharing group and distribution rules	MISP sharing groups and distribution levels, exported as configuration	Who could receive each indicator and that TLP and distribution settings matched the arrangement's rules
Onboarding and admission decisions	Ticketing system approvals linked to the MISP or OpenCTI user record	Why a community or partner was admitted, who approved it and when access was granted
Synchronization logs	MISP server sync logs or OpenCTI connector and worker logs, forwarded to the SIEM	What was pushed and pulled, with which peers, and whether failed transfers were retried
Sharing policy approvals	Document management system with version history, referenced from MISP or OpenCTI settings	That the rules for what the entity shares and redacts were approved by an accountable owner before use
Indicator to detection trail	MISP or OpenCTI export logs, SIEM rule or sensor update records, Suricata or Zeek rule versions	Which shared indicators reached network and endpoint detection and when
Indicator to incident ticket trail	SOAR playbook run history and ticketing system records linked to the source event ID	How shared intelligence was used in a specific incident and what action was taken

What the platform alone does not satisfy

Running MISP or OpenCTI gives an entity the tooling to exchange intelligence, but membership, sharing terms, personal data handling, supplier scope and staffing are decided by national law and internal governance. Each card below is a gap the platform cannot close, and each should be confirmed against your national transposition law and your own legal and risk teams.

National transposition and notification rules

Article 29(4) requires essential and important entities to notify their competent authority when they join an information-sharing arrangement and when withdrawal takes effect. The method, form, recipient and timing are set by national transposition law, which differs across Member States. Confirm with your national competent authority what must be filed, how, and whether the obligation applies to your sector and entity classification before you join any community.

Legal review of sharing agreements

Sharing communities and hubs often rely on membership terms, codes of conduct or agreements that govern what members may publish, how long it may be retained and who may receive it. A MISP sharing group or OpenCTI access policy enforces these rules technically, but it does not decide them. Have counsel review each agreement against your obligations before the first event is shared, and record who approved each community.

TLP handling and distribution policy

Traffic Light Protocol markings and MISP distribution levels only work if analysts apply them consistently. Mis-tagging an attribute can expose a partner's details to a wider audience than agreed. Write a handling standard that states who sets TLP, who can downgrade it, and how sharing groups map to each marking, then test it with sample events before go-live.

Supplier and service provider scope

Article 29(2) allows exchanges within communities that include suppliers or service providers, where relevant. Deciding which providers belong in a community is a legal and risk decision, and each external party needs its own terms, access rules and offboarding. Confirm with your legal team which suppliers may join, which indicators they can see, and how their access ends when a contract does.

Personal data in indicators under GDPR

Indicators such as email addresses, usernames, IP addresses or phishing lures can be personal data when linked to an identifiable person. Sharing them with a community is a processing activity that needs a lawful basis, minimization and retention limits under the GDPR. Confirm with your data protection officer which indicator types may leave your organization, how they are pseudonymized, and when they expire from the platform.

OpenCTI Enterprise licensing decision

OpenCTI Community Edition is licensed under Apache License 2.0, while the Enterprise Edition uses a separate proprietary license. Before standardizing on OpenCTI, list the features your sharing and workflow model needs and check which ones require the Enterprise Edition. Ask the vendor for the Enterprise terms in writing, because a feature gap found after rollout can change the architecture. The OpenCTI Enterprise Edition documentation is the place to start.

Trained analysts and governance

A sharing platform produces value only when someone curates indicators, removes stale data, answers partner questions and reports membership changes on time. Assign named roles for curation, sharing approval, false positive removal and regulator notification, and budget for training on STIX, TLP and the platform itself. Without that governance, the instance becomes a feed collector that no one trusts or can defend in an audit.

How much work does joining a NIS2 sharing arrangement take?

What drives the cost of running MISP or OpenCTI for NIS2 information sharing?

The software cost depends on the platform: MISP is free under AGPL-3.0, and OpenCTI has a free Community Edition under Apache License 2.0. The recurring cost sits in infrastructure, connector and integration work, paid feeds, and analyst curation time. OpenCTI also needs Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, so its hosting footprint is larger than a single MISP instance. If you choose OpenCTI Enterprise Edition, that adds a proprietary license under the OpenCTI Enterprise Edition License. Ask any implementation partner for a quote that separates one-time setup from monthly hosting, feed subscriptions and support.

Can a small security team run a NIS2 sharing node without outside help?

A small team can run MISP if it has Linux administration skills and someone who owns the sharing rules. MISP 2.5 is the recommended version for new deployments, and the project recommends Ubuntu 24.04 with its provided installer, with Docker images, Ansible roles and packages also listed. MISP 2.4 is end of life with security fixes only, so new installs should not start there. OpenCTI is harder to operate because it runs several services and needs a stable RabbitMQ and Elasticsearch layer. Most teams that lack capacity buy setup and upgrades through a fixed-scope engagement, then keep curation in-house.

How long does setting up a NIS2 sharing node take?

Setup time depends on scope: the number of sharing communities, the connectors to SIEM and firewalls, the authentication design, and how much policy work is needed before the first event is shared. A single MISP instance with one community and basic feeds is a much smaller job than a multi-community hub with OpenCTI, STIX exchange and SOAR integration. No public duration figure applies to every entity, so ask a partner for a timeline based on a written scope, and confirm which items are included in the fixed price and which are priced separately.

What does the entity itself have to provide before the work starts?

The entity must supply decisions the platform cannot make. These include a sharing policy that sets which indicators leave the organization, distribution levels and TLP rules, a named owner who approves what is published, and analyst time for reviewing imports. Asset context matters too: a list of internet-facing systems, key business services and sensor locations lets analysts judge whether an indicator is relevant. Notification to the competent authority when joining or withdrawing from an arrangement under Article 29(4) also needs an owner. Agree these inputs in the scope document so the build does not stall waiting for policy.

How much analyst time does curating shared intelligence take?

Curation time is usually the largest recurring effort and is not a licensing cost. Analysts review incoming events, remove false positives, decide which attributes to push to detection, and age out stale indicators. The workload rises with the number of communities, feeds and connected sensors. No researched figure gives hours per week, so estimate it from your own alert volumes and ask a partner to model it with you. Automating enrichment and triage through a SOAR platform can reduce manual steps, but the decisions about what to share still need a person.

How does a proposed NIS2 amendment change the work?

The Commission proposed targeted amendments on 20 January 2026 in COM(2026) 13, including a new small mid-cap category. The proposal still needs approval by the European Parliament and the Council, and Commission pages updated through July 2026 describe it as a proposal. If adopted, it could change which entities are in scope and therefore who needs to join a sharing arrangement. Keep the sharing design modular so that communities, sharing groups and notifications can be added or removed without rebuilding the platform, and confirm the final text with your national authority before committing.

What should a quote for a NIS2 threat intelligence deployment include?

Ask for a written scope that lists the platform version, hosting location and sizing, each connector and integration, the sharing communities and synchronization partners, authentication, backup, upgrade support and documentation. The quote should state what is one-time and what recurs, who pays for each third-party license or feed, and whether OpenCTI Enterprise features are included. Request the assumptions behind any hosting estimate and the support model after handover. DeployOpen does not publish a price list, and a quote follows from the written scope.

How a self-hosted sharing instance goes live

This sequence takes an essential or important entity from legal scoping to a working, tested MISP or OpenCTI instance that is ready to share, with the membership notification filed before the first exchange is treated as live.

Confirm sector and national transposition rules
Legal or compliance leads confirm whether the entity is essential or important under Article 3 and how the national law that transposes NIS2 handles Article 29 arrangements, including which competent authority receives membership notices. Ask the authority directly for its notification format and any sector-specific sharing communities it recognizes. The step is done when the entity has a written note naming the authority, the notice channel and the sharing communities it is eligible to join.
Define sharing policy and TLP rules
The security lead and legal counsel agree what the entity will share, what it will only consume, which personal data is excluded, and how Traffic Light Protocol markings map to MISP distribution levels and sharing groups. Decide who may approve outbound events and who curates indicators. The output is a short approved policy document that the MISP or OpenCTI administrator implements directly, so that configuration reflects documented decisions rather than defaults.
Install MISP 2.5 or OpenCTI in your environment
The platform team deploys the instance inside the entity's own cloud account, data center or network, using the installer, container images or configuration tooling the project supports. For MISP, use version 2.5 rather than 2.4, which is end of life. For OpenCTI, plan the Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage dependencies. The step is complete when the platform passes a health check, backups run, and access is limited to named administrators through the identity provider.
Configure sharing groups and synchronization
The MISP or OpenCTI administrator creates sharing groups and distribution levels that match the approved policy, then sets up synchronization only with communities and partners whose onboarding terms the entity has accepted. Test that an event marked for a restricted group is not visible to others. The output is a documented list of sync connections, their owners and the sharing groups each one can receive, reviewed by the security lead before any connection is enabled.
Connect detection exports
The detection engineering team sets up scheduled exports from the platform to the SIEM, network sensors and SOAR tooling, using formats the platform supports such as Suricata, Zeek and STIX. Only indicators that pass the curation rules flow to blocking controls, while lower-confidence items feed alerting or hunting. Confirm that each export carries its TLP marking and expiry data. The step closes when a test indicator appears in the target detection tool with the expected handling.
Run a test exchange
The administrator creates a test event with synthetic indicators, shares it to a controlled test group or partner instance, and confirms that it arrives with the right distribution, attributes and markings, then confirms that a withdrawal or update propagates. Results are logged with timestamps and the people who checked them. The step is done when the test evidence is filed with the change record, and any mismatches are fixed and retested.
File the membership notification
The compliance lead submits the notice to the competent authority identified in the first step, covering joining the arrangement and recording the date and the community concerned, as Article 29(4) requires. The same process must handle a later withdrawal notice. Keep the submitted notice, the authority's acknowledgment where one is issued, and the internal approval in the evidence file. Do not open live exchanges before this step is documented.
Review the sharing arrangement
The security and compliance leads review the first operating period, checking which events were shared, how false positives were retired, whether sharing groups still match the policy, and whether the national rules or the Commission's pending amendments to NIS2 have changed the notice requirements. Record decisions and schedule the next review. The output is a signed review record that feeds the next policy update.

How DeployOpen scopes and supports a NIS2 sharing deployment

DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted MISP or OpenCTI instances inside your own infrastructure. For NIS2 information sharing, the work starts with a written scope that defines which communities you join, what you share, and how shared intelligence reaches your incident handling and detection tools.

How we scope

Confirm which sharing arrangements and communities your entity intends to join under Article 29, and who will notify the competent authority.
Define distribution levels, sharing groups and TLP rules for what you receive, enrich and publish.
Agree in writing which SIEM, firewall, SOAR and sensor integrations are in scope, with fixed deliverables and timelines.

How we build

Deploy MISP or OpenCTI in your cloud account, data center or air-gapped network, with the dependencies your chosen platform requires.
Configure feeds, taxonomies, synchronization with community instances, and exports to Suricata, Zeek or your SIEM.
Test sharing permissions, correlation behavior and indicator exports against scenarios agreed in the scope before go-live.

How we hand over

Document the architecture, access model, sharing rules, curation steps and upgrade procedure in a form your team can operate.
Provide evidence records that show membership notifications, sharing configuration and incident handling steps for your assessors to review.
Train named operators on daily curation, false-positive handling and how indicators move into incident response.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial build.
Plan platform upgrades around release lifecycles, such as MISP 2.5 maintenance or OpenCTI LTS timing, with a tested rollback path.
Confirm with us which OpenCTI features require an Enterprise license before you commit to the design.

Open source threat intelligence for NIS2 information sharing