OpenCTI for NIS2 information sharing

How OpenCTI supports NIS2 information sharing under Article 29

OpenCTI can run the technical exchange of cyber threat information and keep the records of what was shared, while the decision to join a sharing arrangement, the terms of that arrangement and the notifications to the competent authority remain your organization's duties. Article 29(1) allows essential and important entities to exchange cybersecurity information voluntarily, including cyber threats, near misses, vulnerabilities, indicators of compromise, adversarial tactics, threat-actor information and detection configuration recommendations. OpenCTI's knowledge schema, based on the STIX2 standards, gives most of these categories a typed structure: indicators, attack patterns, threat actors, vulnerabilities and reports can be stored as objects and related to one another. Categories without a direct object type, such as near misses, may need to be recorded as reports under a convention your team defines. Decide which categories your arrangement covers before you configure anything, because that list sets what the platform must accept, filter and export.

For the technical exchange, the platform's TAXII collections and live streams carry indicators and adversary information between your instance and the partners in the arrangement. Confirm with your platform team how each collection is scoped, who can publish to it and which objects it includes, since these settings determine what leaves your environment. For the record trail, the questions are who shared what, when and under which arrangement. Activity monitoring and audit logs are part of the OpenCTI Enterprise Edition, as are organization-based data segregation and authorized members. If your arrangement requires per-organization separation or an audit trail that your assessors can inspect, confirm that the Community Edition meets those needs or that the Enterprise Edition license is in scope. Check this before the first exchange, not after.

Several duties stay outside the platform. Article 29(4) requires essential and important entities to notify their competent authority when they join an information-sharing arrangement and when their withdrawal takes effect. OpenCTI does not send that notice, and no platform setting satisfies it. The platform also does not replace the broader program in Articles 21 and 23, which cover risk-management measures and incident reporting. Shared intelligence can feed those processes, but the policies, roles and reporting timelines belong to your organization. A practical first step is a register that records the arrangement, its owner, the dates you joined or withdrew, and the notifications you sent. Assign one owner for that register and review it whenever the arrangement changes.

NIS2 is Directive (EU) 2022/2555, so it binds entities through the national laws that transpose it, and those laws set much of the detail. Member States had to adopt and publish transposition measures by 17 October 2024, and Article 5 allows them to keep or adopt rules that ensure a higher level of cybersecurity. The notification form, the authority to notify, the deadlines and any extra conditions for sharing will therefore depend on your country. Before you design the workflow, ask your national competent authority or legal counsel which notifications apply to your entity type and what they must contain. Then map the answers to the steps in your OpenCTI configuration and the register you keep, so that the technical exchange and the legal duties stay aligned.

Which NIS2 requirements map to OpenCTI capabilities and configuration

This table compares each NIS2 requirement relevant to Article 29 sharing with the OpenCTI capability that supports it and the configuration to plan. Rows marked Enterprise Edition need that license, and rows that point to Filigran documentation depend on TAXII and live stream details to confirm before design. Read the table as a split: the platform supports the exchange, while notifications and classification remain obligations the entity carries itself.

Requirement	Platform capability	Configuration needed
Article 29(1): exchange of threats, indicators and adversary information	STIX2 knowledge schema and the MITRE ATT&CK connector represent these object types	Enable the MITRE ATT&CK connector and agree which STIX object types each sharing group uses
Article 29(1): exchange of vulnerabilities, near misses and detection recommendations	STIX2 schema can hold vulnerabilities and reports; confirm how near misses are modeled	Define a labeling and reporting convention for near misses and detection configuration
Article 29(1): machine-readable exchange with partners	GraphQL API and stream consumption; confirm TAXII collections and live streams in Filigran documentation	Confirm TAXII and live stream setup with Filigran before designing partner feeds
Article 29(1): exchange with existing sharing tools	Connectors for MISP and other tools import and export data	Configure MISP connector import and export within the agreed sharing scope
Article 29(4): notifying authorities on joining and withdrawal	OpenCTI does not send notifications to competent authorities	Record join and withdrawal dates in governance records and notify through your authority's procedure
Article 3: essential or important classification	Classification is an entity decision that the platform does not determine	Document your classification and the sharing arrangements it governs
Articles 32 to 34: evidence for supervision	Activity monitoring and audit logs (Enterprise Edition)	Enable audit logs under Enterprise Edition and set retention in line with your policy
Separation of data between sharing groups	Organization-based data segregation (Enterprise Edition)	Create an organization per sharing group and set member access to match each arrangement

What Article 29 asks of entities and what it leaves to national law

Article 29(1) asks Member States to make sure entities can voluntarily exchange cybersecurity information. The listed categories are cyber threats, near misses, vulnerabilities, indicators of compromise, adversarial tactics, threat-actor information and detection configuration recommendations. Each one maps to work an OpenCTI team already does: indicators and observables move through TAXII collections and live streams, adversarial tactics map to ATT&CK techniques, and detection recommendations can be attached to report objects linked to the relevant threat actor. The word voluntary matters. The article does not oblige an entity to share any particular item, and it does not name a platform. What it requires is that the route exists, so the sharing your team designs must be a documented choice that can be reviewed and stopped.

Article 29(4) adds the obligation that matters most for daily operations. Essential and important entities must notify their competent authority when they join an information-sharing arrangement, and again when their withdrawal takes effect. These are two events with two dates, and the withdrawal date is the one teams most often forget to track. In an OpenCTI deployment, joining can mean several things: a shared TAXII collection your instance publishes to, a live stream your connectors consume, or a group workspace where other organizations contribute reports. Decide before any data moves which of these counts as joining, who owns that decision, and where both dates will be recorded.

Article 29 leaves the rest to national law. The article does not set the notification format, the submission channel, the content of the notice, or any deadline beyond the two events. Those details come from the national transposition law and the competent authority named under it, and they can differ between Member States. Confirm them locally before the first arrangement goes live. Useful questions include which authority receives the notice, whether it is filed through a portal or by email, what the notice must contain, whether each arrangement needs its own notice, and whether a withdrawal needs a separate filing. Also confirm that your entity is classified as essential or important under Article 3, since the duty in Article 29(4) applies to those two categories.

NIS2 creates no certificate of compliance. Competent authorities oversee entities through inspections, security audits, security scans, information requests and administrative fines, as set out in Articles 32 to 34. No document exists that declares a sharing setup compliant. What an authority can request is evidence: dated notifications, the arrangement terms, records of who was granted access to which collections or streams, and records of withdrawals. Keep these in your operating records from the start. DeployOpen can prepare the configuration, access model and evidence set for an OpenCTI sharing setup, but it does not issue audit reports, attestations or certifications. Independent auditors and the competent authority make those judgments.

Two items need checking before design work starts. First, the NIS2 amendments proposed on 20 January 2026 (COM(2026) 13) are still a proposal that requires approval by the European Parliament and the Council, so confirm the current text of Article 29 and any national changes with your legal adviser. Second, the platform's access model should match the arrangement. Organization-based data segregation is an OpenCTI Enterprise Edition feature, so a team that relies on separate data views for each arrangement should confirm its license tier before committing to that design. Treat the notification register as a controlled record with a named owner, a review date and a link to the collection or stream it covers.

How OpenCTI carries indicators and adversary information between parties

OpenCTI structures its data with a knowledge schema based on the STIX2 standards. Indicators, malware, threat actors, campaigns, reports and the relationships between them are stored as objects in that schema. A partner platform that also understands STIX2 can interpret the same objects, which is why the schema is the foundation for anything you share. The web application and the GraphQL API work against the same model, so automation you build on the API sees the same objects your analysts see in the interface.

For information sharing, the schema decides what travels between parties. Points to plan for:

Shared object types: Confirm which STIX2 objects your partners expect, such as reports, observables or relationships, and whether your sharing agreement covers each one.
Identifiers and provenance: Check how objects record their author, origin and marking before anything leaves the platform.
API access: Decide which service accounts may read or write through GraphQL, and which roles may create or change shared objects.
ATT&CK mapping: OpenCTI can use the MITRE ATT&CK framework through a dedicated connector, so adversary techniques can be linked to the objects you share.
Data segregation: Organization-based data segregation is an Enterprise Edition feature. Confirm whether your arrangement needs it.

Before scoping, confirm with your partners which object types and markings they will accept and how they expect to receive them.

What evidence the platform produces and how to keep it for supervisors

Each card names one record a competent authority or independent auditor may ask for when reviewing how your entity shares information through OpenCTI. For every item, the card states who keeps it, where it should be stored and how to present it. DeployOpen prepares this evidence but does not issue attestations, and the competent authority decides what it accepts.

Sharing arrangement record and notifications

Keep the signed or approved sharing arrangement, the list of participating organizations, and copies of every notification sent to the competent authority when you join the arrangement and when withdrawal takes effect. The compliance owner should hold the master copy, with dates and the name of the person who approved each step. Store it in your document management system, not only in the platform, and show it as a dated bundle with the matching OpenCTI organization entries. Confirm with your authority which format and channel it expects for notifications.

STIX objects, source attribution and connectors

Every indicator, observable, report and threat actor object in OpenCTI carries STIX fields such as created by, creation date and marking. Export a dated sample that shows the source attribution for shared items, together with the configuration of the connectors that imported or streamed them. The platform engineering team should keep connector configurations under version control, with secrets held in a vault, and review them when a feed changes. Confirm which export formats your OpenCTI version supports before promising a specific bundle to an auditor.

Activity monitoring and audit logs

Activity monitoring and audit logs are an Enterprise Edition feature, so confirm that your license includes them before you rely on them as evidence. The security operations lead should define which events are retained, such as logins, changes to sharing settings and exports, and for how long. Send the logs to write-once storage outside the platform and record who can read them. Present them as filtered extracts for a specific period, with the retention rule attached.

Authentication and SSO configuration

Record which authentication strategies are enabled, including local users, LDAP, SAML or OpenID Connect, and the settings that map identity provider groups to OpenCTI roles. Since OpenCTI 7.260224.0, defining and using authentication strategies, including SSO, requires the Enterprise Edition. The identity team should keep an exported configuration baseline and a dated change log, and remove any local administrator accounts that are no longer needed. Show the baseline alongside the identity provider's own records of who can sign in.

Access and segregation settings by organization

Organization-based data segregation is an Enterprise Edition feature, and it determines which organization can see which shared intelligence. Keep an access matrix that lists each organization, its users, its groups, and the markings or sharing rules applied to its data. The platform owner should review the matrix on a fixed schedule and after every onboarding or withdrawal. Present the matrix together with a sample of access tests that show a user from one organization cannot see another organization's restricted items.

Version and LTS license record

OpenCTI versions follow the pattern x.YYMMDD.z, and LTS releases add a -lts.n suffix, so the exact version in use must be recorded for each audit period. LTS releases also require a specific license key, and the key's validity should be tracked alongside the version. The platform owner should keep a dated record of every upgrade, the release notes read before each change, and the license terms. Present this record with the change log so an assessor can match the deployed version to the security fixes it received.

Configuration sequence for a NIS2 sharing deployment

This sequence takes an entity from legal scoping to a tested OpenCTI exchange with a documented exit. Each step names the output you keep, so counsel, security and platform teams can sign off before the next step starts. It assumes a self-hosted platform in infrastructure you control and does not replace legal advice.

Confirm entity status and transposition law
Counsel confirms whether your organization is an essential or important entity under NIS2 and which national transposition law applies, because the directive binds entities through those national measures. Record the sector, the entity classification and the competent authority in a short memo that counsel signs. The output is that memo, which sets the scope for every later step. Do not start the build until counsel has confirmed the classification.
Define the sharing arrangement and terms
Legal, security and management leads agree the arrangement with the other participants. They decide who may join, which information types are shared (threats, indicators of compromise, vulnerabilities, adversarial tactics and detection recommendations, as Article 29(1) lists), how sensitive material is handled, which marking scheme applies and how long shared data is kept. Write these as terms the platform will enforce. The output is a signed arrangement document that maps each information type to a collection or stream you will configure.
Plan the joining and withdrawal notifications
Agree how you will notify the competent authority when you join the arrangement and when your withdrawal takes effect, as Article 29(4) requires. Assign an owner, the reporting route and the internal approval path. Confirm the required content, format and timing with counsel and the authority rather than assuming them. The output is a notification runbook with templates for joining and for withdrawal.
Size and deploy the dependencies
Deploy the platform's dependencies in infrastructure you control: Elasticsearch 8.0 or later or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later, and S3-compatible storage such as MinIO. The published sizing starts at 2 cores and 8 GB RAM for the platform, 2 cores, 8 GB RAM and 16 GB SSD for the search engine, and at least one platform node for every 3 workers. Confirm the final sizing against your expected data volume and connector count. The output is a running dependency stack with backups and a passing health check.
Configure authentication and SSO
Configure how users sign in. OpenCTI supports local users, LDAP, SAML, OpenID Connect and other strategies, but defining and using authentication strategies, including SSO, is an Enterprise Edition feature since 7.260224.0. Confirm your edition and license before the design is final. Test each login path with a non-administrator account and keep a separately controlled emergency administrator account. The output is a tested login path for each participant group.
Set organization segregation and access
Set organization-based segregation so each participant sees only the data its arrangement allows. This is an Enterprise Edition feature. Map organizations, groups and authorized members to the terms in your arrangement document, then test access with accounts from each organization. Confirm that cross-organization sharing happens only through the exchange channels you approved. The output is an access matrix signed by the data owner, plus test results showing that each boundary holds.
Configure connectors, channels and audit logging
Configure the connectors that move data in and out. Use TAXII collections for shared stores and live streams for near-real-time indicators, as your arrangement specifies. Enable activity monitoring and audit logs, an Enterprise Edition feature, and send those logs to your retention store. Check each connector version against the platform release you pinned. The output is a channel inventory listing each connector, its direction, the data type and where its logs go.
Run a test exchange and document withdrawal
Run a test exchange with a consenting partner or a controlled test instance. Confirm that indicators arrive, carry the marking the arrangement requires, and do not reach organizations outside it. Review the audit log entries for the test. Then document the withdrawal procedure: how you revoke access, stop connectors, handle shared data and send the withdrawal notification, and dry-run it once. The output is a passed test record and a tested withdrawal procedure.

What OpenCTI does not cover for NIS2 and who must own it

OpenCTI can store and exchange threat intelligence under a NIS2 Article 29 arrangement, but the legal, reporting and governance decisions around that exchange sit with the entity. The cards below name each gap and the function that should own it before sharing begins.

Legal decision to join or withdraw

Whether an essential or important entity joins a sharing arrangement is a legal and governance decision, not a platform setting. It depends on the national law that transposes NIS2 in each Member State where the entity operates, which may add conditions or guidance beyond the Directive. Legal counsel and the board or accountable executive should confirm the national rules, the scope of participation and the exit conditions before any connector or TAXII collection is enabled.

Notifications to competent authorities

Article 29(4) requires essential and important entities to notify their competent authority when they join an arrangement and when withdrawal takes effect. OpenCTI can hold a record of membership changes and the dates attached to them, but it does not send those notifications. The compliance lead should confirm the notification channel, format and deadline with the authority and assign a named person to submit each notice.

Article 21 and 23 programme around sharing

Information sharing is voluntary under Article 29, but it sits inside the Article 21 risk management measures and the Article 23 incident reporting obligations that apply to the entity. The platform does not decide whether an event is a significant incident under Implementing Regulation (EU) 2024/2690, and that determination must follow the criteria for the entity's sector. The security lead should map who classifies incidents, who reports them and how shared intelligence feeds those decisions.

Trust and legal terms with partners

Each exchange partner needs terms that cover membership, confidentiality, permitted use, attribution, liability and withdrawal. OpenCTI can represent organizations and their sharing rules, but it cannot create or enforce a contract. Procurement and legal teams should agree the terms in writing and confirm that the platform's organization and access settings match what each agreement allows.

Data classification and handling rules

Shared indicators and reports may include personal data, details of third-party systems or information marked for limited distribution. The entity must define its classification scheme, handling rules and retention periods, then configure markings, groups and stream filters in OpenCTI to follow them. The data protection officer and information security owner should review the scheme before any data leaves the platform.

Commission proposal COM(2026) 13

On 20 January 2026 the Commission proposed targeted amendments to NIS2 under COM(2026) 13, including a new small mid-cap category. The proposal still needs approval by the European Parliament and the Council, so it is not yet law. Compliance owners should track its progress, assess whether their entity category or obligations could change, and review sharing arrangements again if the text is adopted.

What drives the cost and effort of a NIS2 sharing deployment

The first cost decision is the edition. OpenCTI Community Edition is licensed under the Apache License 2.0, so the software itself carries no license fee, but the work to install, configure and run it still has to be paid for. OpenCTI Enterprise Edition is governed by the proprietary OpenCTI Enterprise Edition License and is offered on premises or as SaaS. This matters for information sharing because, since OpenCTI 7.260224.0, defining and using authentication strategies, including SSO, is an Enterprise Edition feature. If your sharing users must sign in through your identity provider, the edition choice moves the license cost and the identity integration cost together. Ask the vendor for the license terms in writing and confirm which features your sharing model needs before comparing quotes.

Infrastructure is the largest recurring cost you control. The documented minimums are 2 cores and at least 8 GB RAM for the platform, and 2 cores, 8 GB RAM and 16 GB SSD for Elasticsearch or OpenSearch. OpenCTI's deployment overview also recommends at least one platform node for every 3 workers. Workers consume RabbitMQ messages for asynchronous writes, so the number of connectors and the volume of exchanged indicators drive the node count upward. Redis 7.1 or later, RabbitMQ 3.11 or later and S3-compatible storage such as MinIO add further components. Treat these figures as starting minimums. Ask the implementer to size the deployment against your expected indicator volume and partner count, and to state which hosting costs fall to you in your own cloud or data center.

Configuring connectors and exchange channels is where most build effort sits. For NIS2 Article 29 arrangements, this covers TAXII collections and live streams, import and export connectors, mapping of incoming indicators and adversary information, and access rules for each partner organization. Effort rises with the number of sharing partners, the data types you exchange (indicators of compromise, adversarial tactics, threat-actor information and detection configuration recommendations), and the integrations with tools such as MISP or TheHive. Plan for testing with at least one partner before go-live. A written scope should list each connector, each exchange channel and each test case, so the one-time build cost can be checked against what is delivered.

Legal and governance work stays with the entity. Article 29(4) requires essential and important entities to notify their competent authority when they join an information-sharing arrangement and when their withdrawal takes effect. Your team must decide who sends those notices, what terms govern sharing, and how partner data is marked and handled. National transposition laws shape these duties, so confirm the requirements with counsel and your national authority. Upgrades are the main recurring technical cost: OpenCTI LTS releases require a specific LTS license key, receive only critical bug and security fixes after a one-month stabilization, and run for one year. In the quote, ask for a written scope, named deliverables, and a clear split between one-time build items and recurring items such as hosting, license renewals, and upgrade support.

Questions buyers ask before hiring help with NIS2 information sharing

Does NIS2 require my organization to share cyber threat information?

No. NIS2 does not oblige entities to share cyber threat information. Article 29(1) requires Member States to ensure that essential and important entities can exchange cybersecurity information voluntarily, including indicators of compromise, adversarial tactics, vulnerabilities and threat-actor information. The procedural duty applies only if you choose to join. Under Article 29(4), an entity that joins an information-sharing arrangement must notify its competent authority when it joins, and again when its withdrawal takes effect. Because NIS2 is applied through national transposition laws, ask your counsel to confirm any additional requirements in your Member State and sector.

Does running OpenCTI make my organization NIS2 compliant?

No. OpenCTI supports the technical side of sharing. It stores and relates threat data in a STIX2-based schema and can exchange it through TAXII collections and live streams. It does not decide who you share with, what you share, what your sharing agreement says, or how personal data is handled. Notifying the competent authority is a process your legal and compliance teams own. NIS2 also creates no certificate of compliance. Authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. OpenCTI records can help you evidence activity, but they are one input to a wider program.

How long does an OpenCTI deployment for information sharing take?

No duration has been set in a written scope yet, so ask for one before you plan. The timeline depends on scope, dependencies and approvals. Scope covers how many sharing communities you join, which data sources and connectors you feed, and whether you need SSO and data segregation. Dependencies include the search, cache, message queue and object storage services OpenCTI requires, which may need new infrastructure or hardening. Approvals include legal review of sharing arrangements, security sign-off on data flows and change windows. Ask any provider to break its estimate into these phases and to list what it assumes you will provide.

What does an information-sharing deployment need from my team?

Expect input from three groups. Legal or data protection counsel reviews the sharing arrangement, what may be shared, how personal data is handled and the notification steps under Article 29(4). Security operations decides which indicators and reports are shared, who triages incoming data and how it links to existing detection and case tools. Identity and infrastructure owners provide SSO, directory access, network paths, the hosting platform, storage, backups and monitoring. Someone must also own the platform after go-live, including upgrades. Agree these roles and a named decision-maker in the written scope before work starts.

Can my own team deploy OpenCTI for NIS2 sharing without a partner?

Yes, if your team has the skills. A team with experience in Linux, containers, identity, search clusters and the STIX2 data model can deploy OpenCTI using the vendor's documentation, which covers deployment, dependencies and authentication. The harder work is often non-technical: agreeing sharing rules, notification procedures and evidence records. Staffing matters over time. The platform releases on a regular cadence, and LTS releases require a specific LTS license key. If you build in-house, assign an upgrade owner and set up a test environment before connecting live feeds.

What does OpenCTI Enterprise Edition add, and do I need it?

It depends on your access and segregation requirements. The Enterprise Edition adds activity monitoring and audit logs, playbooks, organization-based data segregation, authorized members, full-text document indexing, AI features, priority intelligence requirements and SSO configuration. Since OpenCTI 7.260224.0, defining and using authentication strategies, including SSO, is an Enterprise Edition feature. You are likely to need it if you must use SSO for the sharing platform or keep data separated between organizations. A single-team pilot may not. Filigran offers the Enterprise Edition on premises or as SaaS, with trial licenses. Confirm license terms directly with Filigran.

How do DeployOpen fixed-scope engagements and retainers work?

Most DeployOpen engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. Ask that the scope name the platform components, connectors, integrations, identity setup, backup and test steps, documentation and handover, along with the client inputs and approvals it assumes. Ongoing support, upgrades and continuous testing are available as retainers, which suit platforms that need regular release tracking and maintenance after go-live. DeployOpen does not publish a price list. When you compare proposals, ask which costs are one-time, which recur and what drives each up or down.

Which technical dependencies must be in place before OpenCTI goes live?

Prepare these services first: Elasticsearch 8.0 or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later, and S3-compatible storage such as MinIO. OpenCTI's documented sizing starts at 2 cores and at least 8 GB RAM for the platform, and 2 cores, 8 GB RAM and 16 GB SSD for Elasticsearch or OpenSearch. Python workers consume RabbitMQ messages for asynchronous writes, and the documentation recommends at least one platform node for every 3 workers. Connectors handle import, enrichment, file extraction, export and stream consumption. Treat these figures as starting points and confirm sizing against your expected data volume.

How DeployOpen scopes, configures and documents NIS2 sharing support

DeployOpen plans, implements, hardens, documents and supports self-hosted OpenCTI in your own cloud accounts, data centers or air-gapped networks. For NIS2 information sharing, we start from the written scope, agree which TAXII collections and live streams your arrangement needs, and document the notification steps your organization owns under Article 29. Engagements are fixed-scope, with ongoing support available as a retainer.

How we scope

The written scope names the sharing arrangement, the participating parties and the data categories to exchange.
Scope covers which OpenCTI TAXII collections and live streams are published, consumed and restricted.
Scope also lists the notification duties on joining and withdrawal under Article 29(4), which your organization confirms with its authority.

How we build

Deploy OpenCTI with its platform, workers, RabbitMQ, Redis, Elasticsearch or OpenSearch, and S3-compatible storage in your environment.
Configure the TAXII feeds and live streams, with connectors and access rules that match the sharing agreement.
Set up authentication, and confirm whether your chosen SSO strategy needs the Enterprise Edition license.

How we hand over

Test imports, exports and stream consumption against agreed sample data before the platform goes live.
Document the architecture, sharing workflows, access model and notification steps as a handover pack.
Prepare evidence for your own assessments. DeployOpen does not issue audit reports or certifications.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing.
Plan OpenCTI upgrades around the release and LTS lifecycle, including database migrations, before each change.
Review the Article 29 arrangement and notifications when national transposition or pending EU amendments change.