Collabora Online security measures for NIS2

How to apply NIS2 risk management measures to self-hosted Collabora Online: patching, supply chain evidence, access control, incident logging and supported versions, and what remains outside the platform.

On this page

How Collabora Online helps meet NIS2 risk management measures

If your organization is an essential or important entity under NIS2 and hosts document editing in its own infrastructure, the Article 21 risk management measures apply to that service as they do to the rest of your network and information systems. A self-hosted Collabora Online deployment helps with several of these obligations: patching from published advisories, access control through the WOPI host, the ability to keep unsupported versions out of production, and configuration records that feed supply chain reviews. It does not satisfy NIS2 on its own. Access policy, backups, incident handling, staff training and supplier management remain your responsibility, and the software does not perform them for you.

NIS2 is Directive (EU) 2022/2555, applied through national transposition laws, so the exact duties depend on your Member State and sector. Commission Implementing Regulation (EU) 2024/2690 sets the technical and methodological requirements for the Article 21(2) measures for certain digital infrastructure and service providers, so confirm with your national authority whether it applies to you directly. NIS2 creates no certificate of compliance. Competent authorities oversee entities through inspections, audits, scans and information requests, and Article 23 requires reporting of significant incidents within the timelines set by national rules. Confirm those timelines with your national competent authority before you write the incident procedure for the editing service.

DeployOpen can prepare the configuration, the update procedure and the evidence files that show how your Collabora Online deployment meets your chosen Article 21 measures, including records of advisories reviewed and changes applied. DeployOpen does not issue compliance attestations or certifications, and independent assessment remains with your competent authority or your auditors. The Commission's February 2026 proposal to amend NIS2, COM(2026) 13, would add a small mid-cap category, but it has not been adopted, so plan against the current Directive and track the proposal as it moves through Parliament and Council. The NIS2 Directive page from the European Commission is a useful starting point for confirming your obligations.

Mapping NIS2 Article 21 measures to Collabora Online capabilities

This table maps NIS2 Article 21 measure areas to what Collabora Online and its WOPI host can be configured to do, and names the configuration each row depends on. Read each row as a starting point for your own risk assessment: rows marked for confirmation describe needs that the supplied documentation does not settle, so verify them with Collabora or in a test environment before relying on them.

Measure areaCollabora Online capability and configurationNextcloud or WOPI host control that also applies
Risk analysis and policiesNo Collabora feature replaces your risk assessment. Record the editor as a component in your asset inventory, with version, deployment method and the WOPI hosts that call it.Define which groups may open and edit documents in Nextcloud Office, and document that policy as part of your risk register.
Incident handlingCollabora publishes security advisories. Subscribe to them and record which point release fixed each one, for example 25.04.7.5 fixing CVE-2026-23623. Confirm with Collabora how advisories are notified to CODE users versus subscribers.Restrict WOPI requests to the Collabora server IP addresses so unexpected callers are rejected. Collect host and proxy logs for the editor endpoints so you can reconstruct events.
Business continuity and backupsCollaborative sessions are tied to a single pod, so plan replica count and failover behavior before go-live. Confirm with Collabora how recovery of in-progress sessions is handled. Back up the configuration and the Helm values or package settings, not the editor's working state.Document documents' storage location in the WOPI host, since the host, not the editor, holds the files and their backups.
Supply chain securityThe server code is MPL-2.0 licensed, and the Business plan includes signed security updates and customer portal access. Confirm package signing key rotation steps for RPM and DEB installs, which were updated in the 25.04 line.Keep your Nextcloud Office app version pinned and tested against the Collabora version you deploy, and retain both version records as supplier evidence.
Vulnerability handlingApply point releases within your own patch window. Track the 25.04 branch, which was still receiving point releases, such as 25.04.13 released on September 21, 2026. Confirm end-of-support dates for your branch with Collabora before planning upgrades.Test point releases against your Nextcloud version and document the test result before rollout.
Access controlUse the WOPI host for user identity, since the editor does not manage users. The Nextcloud guidance covers limiting editor use and edit rights to chosen groups, which narrows who can change documents.Limit which groups can use the editor and which can edit rather than only view. Review these group assignments on a fixed schedule.
CryptographyUse HTTPS for the Collabora server URL, using the same protocol as the Nextcloud installation. Confirm how TLS is terminated at your reverse proxy or ingress and which cipher policy applies.Use HTTPS on the Nextcloud side as well, so the WOPI exchange does not mix protocols.
Secure configuration and networkRun replicas behind a load balancer that routes by the WOPISrc parameter, and set replica counts manually because autoscaling breaks collaborative editing. Confirm the resource limits for your load with Collabora.Restrict WOPI requests to the Collabora server IP addresses. Review the allow list whenever the editor is moved or scaled.

How to patch Collabora Online from security advisories

Patching is where NIS2 risk management becomes visible in day-to-day operations. The cards below follow one cycle: watch the advisories, pick a supported branch and channel, apply signed packages, test, and record what changed. Each step produces evidence you can show a competent authority or an assessor.

Watch advisories and release notes

Collabora publishes security advisories alongside its release notes, and the 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623. Assign one owner to check the release notes page on a fixed schedule and to subscribe to the forum announcements. Log each advisory you review, including the ones that do not apply to your version, so the review itself is on record.

Choose a supported branch

Run a branch that still receives point releases. The 25.04 branch was first released on June 19, 2025 and was still receiving point releases in 2026, with 25.04.13 released on September 21, 2026. Confirm the end of support date for your branch with Collabora before you commit, because a branch past that date will not receive the fixes you need for evidence of timely patching.

Choose a production channel

CODE is a free rolling edition released on average once a month, and Collabora does not recommend it for production. A production server should follow a stable branch with planned point releases. The channel you choose decides how patches reach you, how far behind you can fall, and how much testing each change needs. Record the channel as part of your configuration baseline.

Apply signed packages and updated keys

For RPM and DEB installations, verify the package signature before installation and keep the signing keys current. The 25.04 release notes record that package signing keys were updated for RPM and DEB users, so a key rotation can break installs that rely on old trust settings. Check the signing key version against Collabora's documentation during each update and store the verification output with the change record.

Test before production

Apply each point release to a staging copy that mirrors your WOPI host, ingress, TLS settings and a representative set of documents. Confirm that editing, saving, copy and paste, and the WOPI allow list still behave as before. Keep the previous package available so you can roll back if the test fails. Agree the test scope and acceptance criteria in writing before the change window opens.

Decide whether to buy signed updates

The Business plan costs 3 euros per user per month for up to 99 users, according to Collabora's pricing page, and includes long term support, a service level agreement, signed security updates and customer portal access. Compare that recurring fee with the internal effort of tracking advisories, verifying packages and maintaining a branch yourself. Ask Collabora to confirm what the service level agreement covers and how security updates are delivered.

Record each patch for NIS2 evidence

A patch record should show the advisory reference, the affected and fixed versions, the date the advisory was reviewed, the risk assessment and the decision taken, the test evidence, the approval, the deployment date and the post-change check. Keep records for every host, including staging and any CODE instances used by teams. NIS2 creates no certificate, so these records are the evidence you bring to an inspection or audit.

What supply chain evidence NIS2 reviews will ask for

Article 21 of NIS2 expects an entity to manage risk in its supply chain, and for self-hosted Collabora Online that starts with evidence you hold about the code you run. The server code is licensed under the Mozilla Public License 2.0 (MPL-2.0), as stated in the COPYING file of the CollaboraOnline/online repository, so you can record your license position from a source you can cite. Active development happens on Collabora's Gerrit instance, and the GitHub repository is used as an issue tracker. Record both locations in your supplier file. Base your review of changes and fixes on the Gerrit history and published release notes, and treat the issue list as a secondary signal. Keep a dated copy of the license review with the deployment record.

The second part is provenance for the artefact you actually run. Collabora Online can come from the collabora/code Docker image (listed for x86-64, ppc64 and arm64), from system packages, or from the official Helm chart. Whichever you choose, record the exact version, the image digest or package file hash, the source you pulled it from, the date, and the person who approved it. For RPM and DEB installs, the 25.04 release notes record that package signing keys were updated, so store the key fingerprints you trust, verify signatures at install, and log every key change as a change record. CODE is described as not recommended for production, so a production deployment needs a supported agreement that states which updates and notices you will receive.

Configuring access control and logging for NIS2 readiness

This sequence narrows who and what can reach the editor, sets the routing and resource settings that keep collaborative sessions stable, and produces a logged, documented baseline that you can show to a supervisor or auditor. Each step ends with a check you can record.

  1. Restrict WOPI requests to Collabora addresses

    The Nextcloud administrator restricts WOPI requests so that only the IP addresses of your Collabora Online servers can call the WOPI endpoints, as the Nextcloud administration manual recommends. Your network team supplies the server addresses from the actual load balancer or egress path, which may differ from the pod or host address in your design. Confirm the address list with a test request from an address outside the list, which should be refused, and a request from inside the list, which should succeed.

  2. Match the Collabora server URL protocol

    Set the Collabora Online server URL in Nextcloud to use the same protocol as the Nextcloud installation, preferably HTTPS, so that editing traffic and the WOPI callbacks do not fall back to an unencrypted path. The platform team confirms the certificate chain is trusted by both servers. The check is that the URL in the Nextcloud Office settings starts with the same scheme as your Nextcloud address and that a document opens without mixed-content or certificate warnings.

  3. Limit editor and edit rights by group

    In the Nextcloud Office settings, the administrator limits which groups can use the editor and which groups can edit rather than only view. Map these groups to the roles your access policy already defines, and record who approved each group. The check is a test account outside the permitted groups that cannot open a document in the editor, and a view-only account that opens a document but cannot save changes.

  4. Route by WOPISrc with fixed replica counts

    The platform engineer sets replica counts manually in the Helm chart, because the chart README states that horizontal pod autoscaling is disabled since scaling breaks collaborative editing and copy and paste. The ingress controller, whether Nginx, HAProxy or OpenShift Router, must route by the WOPISrc parameter so that everyone editing one document reaches the same pod. The check is two users opening the same document from different browsers and confirming in the logs that both requests reached the same pod.

  5. Apply the chart resource requests and limits

    The platform engineer sets pod resource requests to 4 CPU cores and 6000 MiB of memory, with limits of 8 CPU cores and 8000 MiB, as the Helm chart README recommends for production. Capacity planning above these values belongs to the sizing work for your user count. The check is the rendered manifest or the running pod spec showing those exact values, and no pod being evicted or restarted under a normal editing load in the test window.

  6. Centralize ingress and host logs

    The security operations team forwards ingress access logs, Collabora Online server logs and host events from the Nextcloud and Collabora hosts to a central log platform you control. The exact fields to capture, the retention period and the alerting thresholds depend on your environment and your regulator's expectations, so confirm them with your compliance lead before going live. The check is a test editing session that produces matching entries in the central store, with timestamps synchronized across the hosts.

  7. Document the baseline and patch calendar

    The operations lead records the configuration baseline, including the WOPI address list, protocol settings, group mappings, Helm values and resource settings, and stores it under change control. A patch calendar then names who checks Collabora security advisories, who tests new releases and who approves rollout, using the release notes and advisories published by Collabora. The check is a dated baseline document that matches the running configuration, with a named owner for each advisory check.

Essential or important entity: what changes for document editing

Entities classified as essential under NIS2 face ex ante supervision, meaning the competent authority can check compliance before an incident occurs, not only after one. For a team that self-hosts Collabora Online, this means the security evidence for the editing service should exist and be current at all times, not be assembled when an inspector asks for it. The Article 21 risk-management measures and the Article 23 reporting duties apply in full.

  • Continuous evidence: Keep configuration baselines, the running version and the list of applied advisories current for the Collabora Online servers.
  • Documented risk assessment: Record how editing service risks are identified, rated and accepted, and who approves each decision.
  • Reporting readiness: Define who decides that an incident is significant and how early warnings and follow-up reports reach the national authority in the required timeframes.
  • Supervision requests: Expect information requests, scans and audits, and assign one owner to answer them.
  • Supplier evidence: Hold current supplier and version information for the editing platform and its dependencies.

Ask your national authority or legal adviser how ex ante supervision is applied in your Member State and what it expects to see for document editing.

What Collabora Online does not cover for NIS2

Collabora Online is one component of your NIS2 risk management measures under Article 21. The gaps below sit with the entity, its host platform and its governance, and no editor release closes them. Each card names what you must provide before a supervisor asks.

Incident reporting timelines

Article 23 sets reporting obligations for significant incidents, and Implementing Regulation 2024/2690 defines the criteria that make an incident significant for the in-scope service types. Collabora Online will not tell you whether an event meets those criteria. You must build the detection path, the decision owner and the clock for early warning, notification and final report. Ask your team to test this with a tabletop exercise that includes a suspected editor compromise.

Business continuity for the host platform

Your continuity plan must cover the whole document chain: the WOPI host, its database, file storage, identity provider, load balancer and the Collabora Online servers. Losing one component can stop editing even when Collabora itself is healthy. Define recovery objectives for each layer, record who restores what, and rehearse a restore from backup. Collabora Online holds no document store of its own to protect.

Authentication and authorization in the host

Collabora Online does not decide who may open or edit a document. The WOPI host does, through its own sign-in and sharing rules. Nextcloud can limit which groups use the editor and which groups may edit rather than only view. Review those group settings, test them with accounts from each role, and record the outcome as access evidence. Your identity provider settings and session lifetimes remain your responsibility.

Risk analysis and governance policies

Article 21 requires policies on risk analysis and information system security, along with management oversight and accountability. A component inventory and a patching record help, but they do not replace a documented risk assessment that names Collabora Online, its hosts and its data flows. Management must approve the policy and review it. Ask your compliance lead to map the deployment to a written risk register before the first supervisory inquiry.

Staff training

Article 21 expects cybersecurity training for staff, and management bodies carry their own obligation to be trained. Administrators who change WOPI allow lists, upgrade servers or handle advisories need documented competence for those tasks. Build a short course covering the update process, the host's sharing model and the escalation path for an advisory. Keep attendance records and refresh them when the deployment changes.

Supervisory relationship with the authority

NIS2 creates no certificate of compliance. National competent authorities oversee entities through inspections, security audits, security scans, information requests and administrative fines. Essential and important entities face different supervision regimes under Articles 32 and 33. Confirm with your national authority which regime applies, who speaks for the organization, and which evidence they expect. Collabora has no NIS2 certificate, and DeployOpen does not issue audit reports or attestations.

Questions buyers ask about NIS2 and Collabora Online

Does self-hosting Collabora Online make my organization NIS2 compliant?

No. NIS2 creates no certificate of compliance, and self-hosting Collabora Online does not make an entity compliant on its own. It contributes evidence to the risk management measures under Article 21, such as patch records, configuration baselines, access settings and logs. Whether those measures are sufficient depends on your sector, your entity classification as essential or important, your national transposition law and your wider risk management process. Confirm your obligations with your national competent authority or legal counsel before scoping any work.

What does a Collabora Online NIS2 engagement cost, and what drives the price?

The software is free to download under MPL-2.0, but a supported deployment has its own costs. Collabora's pricing page lists a Business plan at 3 euros per user per month for up to 99 users, including long term support, a service level agreement, signed security updates and customer portal access. Enterprise plans for 100 or more users are quoted with volume discounts. Implementation effort depends on the number of Collabora nodes, the WOPI host integration, how evidence is designed and whether you choose a subscription. Ask for a quote that separates one-time work from recurring subscription and support fees.

How long does it take to apply these measures to a Collabora Online deployment?

Duration depends on the written scope, so ask for a timeline as part of the quote. The main variables are the number of servers and pods, how many WOPI hosts you connect, whether a patching process already exists, and how much evidence must be designed from scratch. A fixed-scope agreement sets deliverables and dates before work starts. Ask for each milestone, the change windows it needs and which items depend on your own teams.

Can our own team handle NIS2 measures for Collabora Online without a partner?

A small team with time to track Collabora's security advisories, apply patches and write down what it does can handle routine operations. Evidence design and host configuration usually need someone who has done it before. The WOPI host allow list, access settings in the host platform and the logs you need for incident reporting are easy to get wrong, and gaps often appear only when an authority asks questions. Decide which parts your team will own and which parts you want reviewed.

What do we need to provide before a NIS2 engagement starts?

Plan for access to the WOPI host platform and its administration console, the Collabora servers or Kubernetes cluster, and the network paths between them. You also need change windows for upgrades and restarts, and named owners for patching, access reviews and incident contact. The work must fit inside your existing risk management and incident processes, so bring your current policies, asset inventory and reporting procedures. Missing any of these usually extends the timeline.

Which Collabora Online versions should we run to keep patching manageable?

Run a version that still receives security fixes, and confirm its support status before you commit. Collabora publishes security advisories, and its 25.04 release notes show point releases continuing into 2026, including a fix for CVE-2026-23623 in 25.04.7.5. CODE is a rolling release not recommended for production, so production deployments usually use a supported branch. Check the release notes for your branch and agree in writing how quickly security updates will be applied.

Does NIS2 require supply chain evidence for document editing software?

NIS2 Article 21 includes supply chain security among the measures entities must consider, and the Implementing Regulation (EU) 2024/2690 sets technical requirements for certain digital service providers. For an in-scope organization, supplier evidence for Collabora Online can include the license, the release channel, signing and update practices, and a software bill of materials where available. Ask Collabora which evidence it provides under your subscription, and confirm the requirements that apply to your sector with the competent authority.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Collabora Online, that means treating NIS2 risk management measures as a written scope covering patching, access control, logging and supported versions, with evidence produced as the work is done.

How we scope

  • Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
  • The written scope names the WOPI hosts, Collabora Online branches, networks and hosting locations in your environment.
  • Scope confirms who in your organization owns advisory monitoring, change approval and incident reporting decisions.

How we build

  • Configuration covers WOPI host allow lists, TLS, group-based access limits and Collabora Online version pinning in your infrastructure.
  • Patching runbooks are written against Collabora's published advisories, with test environments used before production changes.
  • Logging and monitoring are set up so that editor, proxy and host events can be reviewed during an incident.

How we hand over

  • Deliverables include configuration baselines, runbooks, a patch and upgrade procedure, and an evidence map for your assessors.
  • Documentation records which control areas are covered by the deployment and which remain your organization's responsibility.
  • Handover includes a walkthrough with your security and platform teams so they can operate the controls without us.

How we support

  • Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the initial scope.
  • Retainers can cover tracking of new advisories and applying point releases on the branch you run.
  • Compliance readiness work prepares systems and evidence, while independent auditors and authorities make the formal assessment.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.