Collabora Online SBOM and EU CRA supplier review

How the Collabora Online SBOM fits your Cyber Resilience Act work

An organization that runs Collabora Online and faces a supplier review or a Cyber Resilience Act (CRA) preparation project needs to know what the SPDX 3.0.1 SBOM published from 26.04 can settle. The SBOM supports vulnerability management and supplier assessments, but on its own it does not meet any CRA obligation. It is an inventory of the components in a release. It shows which packages and versions make up the build you run, so you can match published advisories against your deployment and answer a supplier questionnaire with evidence. Treat it as an input to your process. Check it against the exact version and image you deploy, because a component list for one release does not describe a package that has been rebuilt or patched since.

The CRA places most obligations on the manufacturer, the party that develops a product and places it on the EU market under its own name. The regulation applies from 11 December 2027, while the Article 14 reporting obligations apply from 11 September 2026. The essential cybersecurity requirements in Annex I, including the vulnerability handling requirements in Part II, are the manufacturer's to meet. Collabora's public material helps with the inputs: a component inventory, a stream of security advisories such as the record of CVE-2026-23623 fixed in 25.04.7.5, and signed packages. The conformity assessment, technical documentation, risk assessment and reporting to authorities remain the manufacturer's work, including for an organization that substantially modifies the software or distributes it under its own brand. The text of Regulation (EU) 2024/2847 is the place to check each obligation against your role.

If you deploy Collabora Online inside your own organization without changing it, your main CRA exposure is operational: keep the deployed version on a supported branch, apply point releases promptly, and record which SBOM matched each deployment. Confirm with Collabora whether your plan includes signed security updates and customer portal access, and ask how the SBOM is versioned across 26.04 and later releases. Then decide whether any custom integration, plugin or change to the host platform would make you a manufacturer of a product placed on the market. Read the Commission's guidance on applying the regulation, published on 27 July 2026, which covers substantial modification and free and open-source software, and confirm your position with legal counsel before you rely on it.

Mapping CRA requirements to Collabora Online documentation

This table maps the Cyber Resilience Act requirements most likely to affect a Collabora Online deployment to what Collabora documents, what your team must configure and what remains open. Read the manufacturer rows for Collabora's own duties and the deployer rows for the steps your organization controls. The main takeaway is that the vendor's SBOM and advisories support your review, but your inventory, patch records and legal role assessment stay with you.

Requirement	What the platform documents	Configuration you need	What remains open
Article 14 reporting from 11 September 2026	Collabora is the manufacturer and reports to the CSIRT designated as coordinator through ENISA's Single Reporting Platform.	Confirm in writing how Collabora handles reporting for the versions you run.	Whether your organization takes on any manufacturer role through modification or redistribution. Confirm with counsel.
Full application date 11 December 2027 (Article 71(2))	Release notes show branch timelines, such as 25.04 still receiving point releases, with 25.04.13 released on September 21, 2026.	Record the branch in use and plan upgrades before support windows close.	Which products placed on the market before this date you must treat as in scope. Ask your assessor.
Vulnerability handling (Annex I, Part II)	Security advisories, including the 25.04.7.5 fix for CVE-2026-23623 released January 29, 2026.	Subscribe to advisories, log patch dates and version numbers for each host.	Your internal patch deadline and how quickly Collabora ships fixes for your branch. Confirm in the contract.
Signed packages and update integrity	Package signing keys were updated for RPM and DEB users, as recorded in the 25.04 release notes.	Verify package signatures and keep key import records during each rollout.	How signing works for Docker images and for any builds you produce yourself.
Software bill of materials	An SPDX 3.0.1 SBOM is published from 26.04 onward.	Import the SBOM into your vulnerability tool and match it to the deployed build.	Whether the SBOM covers bundled third-party components and whether earlier branches have one. Confirm with Collabora.
Free and open-source software guidance (27 July 2026)	Server code is licensed under MPL-2.0, and the guidance covers free and open-source software in scope.	Keep the license record and document Collabora as a component in your product inventory.	How the guidance applies to a self-hosted office component inside your own service. Confirm with counsel.
Harmonized standards (M/606)	Collabora does not publish a mapping of its product to the requested standards in the sources reviewed.	Ask which harmonized standards the vendor intends to apply to Collabora Online.	Which of the 41 requested standards will be published and when. Track the Commission's progress.
Penalty exposure (Article 64)	No penalty information is provided by the vendor, as penalties apply to the operator of the obligation.	Keep accurate statements in notifications and records provided to authorities.	Your exposure depends on your role. Maximum fines range from EUR 5 million to EUR 15 million, or a turnover percentage.

Which CRA dates and roles apply to your deployment

The first date to plan around is 11 September 2026, when the reporting obligations in Article 14 of Regulation (EU) 2024/2847, the Cyber Resilience Act, began to apply. Those obligations cover manufacturers reporting actively exploited vulnerabilities and serious incidents, and they reach every in-scope product whenever it was placed on the market. The regulation applies in full from 11 December 2027. Products placed on the market before that date fall under the wider requirements only if they are substantially modified on or after it, so an older deployment is not automatically in scope for the essential requirements. Whether a change to your installation counts as a substantial modification is a legal question, and you should confirm it with counsel before you decide that the earlier date gives you room.

Most of the obligations attach to the manufacturer, meaning the party that develops a product or has it designed and places it on the EU market under its own name. An organization that downloads Collabora Online and runs it in its own cloud account or data center is normally not the manufacturer of that software. It is the deployer, and its duties are closer to operating a product safely than to meeting the design and reporting duties. Several roles can apply at once, though. If you package and distribute a modified build, customize the software and offer it commercially, or sell a product that embeds it, your position changes. Confirm your role for each product and each distribution path, and record the reasoning.

The Commission's non-binding guidance of 27 July 2026, published as the annex to Communication C(2026) 5252, addresses free and open-source software, substantial modification and the treatment of products developed outside a commercial activity, so it is the right starting point for that analysis. Ask counsel to check the guidance against your specific facts, including whether your own configuration changes, custom integrations or hosting arrangements could count as modifications. Keep a dated record of your role assessment so that it can be shown to an auditor or authority later. The regulation text is available on EUR-Lex.

Where the Collabora Online SBOM helps in vulnerability management and supplier reviews

The SBOM is most useful when you match it against a fixed release, a dated advisory or a written supplier question. Each use depends on one thing: an inventory that names the exact Collabora Online version you run. Each card states what you must still do yourself and what the file cannot answer.

Match component versions to advisories

Collabora publishes security advisories for Collabora Online, and the SBOM gives you the list to check them against. Record the exact release you run, then compare the components it lists with the affected versions in each advisory. Confirm whether a flagged library ships in your Linux package, Docker image or Helm deployment, and set your patch window from that result. The SBOM cannot show whether a flaw is exploitable in your configuration, so review the advisory text and your WOPI exposure yourself.

Answer supplier questionnaires with one inventory

Customers and auditors often ask which open-source components sit inside the editor and at which versions. Keep one versioned SBOM per deployed release, stored alongside your configuration baseline, so every answer matches what actually runs. Ask Collabora to confirm that the file covers the packaging you use, whether that is a system package, the collabora/code image or the Kubernetes chart. The SBOM does not describe how Collabora builds, signs or hosts its releases, so request that evidence separately.

Review licenses for server and dependencies

The Collabora Online server code is licensed under MPL-2.0, as stated in the COPYING file. The SBOM should list the license of each component, but you still need to work out your obligations for the server and for every third-party component you distribute. Check that the license data is complete, and decide how you will meet notice and source availability duties. The SBOM records declared licenses, not a legal conclusion on compliance, so involve counsel where you modify or redistribute the software.

Track the branch against its support period

An SBOM describes the release it came with, so it stays useful only when you also record which branch and point release is live. Compare your branch's support window with your own support plan, and schedule the move to a newer branch before support ends. Confirm end-of-life dates and what your subscription covers with Collabora, because the SBOM does not state end-of-life dates. Keep the branch and point release in your asset register so that scanners and reviewers read the same version.

Document the version change in upgrades

Every upgrade should change the SBOM record together with the configuration. Store the previous and new SBOM, the release numbers and the advisories each change addresses in the same change record. Compare the two files to see which packages were added, removed or changed before testing starts. The comparison shows changes in the inventory, not whether document rendering and collaboration still behave correctly, so test those separately. Retain these records for as long as your audits and regulators expect.

Setting up SBOM intake and version tracking for Collabora Online

This sequence keeps a verified record of the exact Collabora Online build you run, the SBOM that describes it, and the advisories that apply to it. Each step leaves an artifact that a reviewer, scanner or supplier questionnaire can check against your live deployment.

Record the exact Collabora Online version and branch
The platform or operations lead records the full version, the branch (for example 25.04 or 26.04), the install method (Docker image, system packages or the Helm chart) and every host or cluster running it. If a team runs the free CODE edition, note it, because Collabora describes CODE as a rolling release not recommended for production. Production should run on a fixed branch with a planned update path. Done when the record matches what the running container, package manager or Helm release reports.
Obtain the SBOM for that release
The platform lead requests or downloads the SBOM from Collabora's published release materials for your exact release. Confirm with Collabora which file, format and version applies to your branch, since the topic scope names an SPDX 3.0.1 SBOM published from 26.04. For earlier branches, ask Collabora what supplier evidence exists. Verify any published checksum. Done when the file name and release identifier match the version recorded in the previous step.
Store the SBOM with the deployment record
The team saves the SBOM in version control or the change management system, named with the Collabora Online version, the branch and the date received. Record the source location and checksum in the same entry, and link the entry to each deployment that uses that build. Keep superseded SBOMs rather than overwriting them, so past deployments remain traceable. Done when a reviewer can retrieve the SBOM that matched any deployment that has run.
Load the SBOM into scanning and inventory tools
The security engineer imports the SBOM into the vulnerability scanner, software composition analysis tool or asset inventory. Not every tool parses every SPDX version, so confirm the tool supports the format before relying on it. Check that the imported component record identifies the Collabora Online build, and review the component list for coverage gaps. Done when a test scan associates the Collabora Online component with the version recorded in step one.
Subscribe to release notes and security advisories
The platform team subscribes a shared mailbox or ticket queue to Collabora's release notes and to its forum announcements, and records where advisories are published. Advisories can apply to a specific branch and can include package signing key updates for RPM and DEB users. For example, the 25.04 release notes record 25.04.7.5, released January 29, 2026, as fixing CVE-2026-23623. Done when a named owner receives each notice and advisory identifiers are logged against the recorded version.
Set a review cadence that drives patch decisions
The change owner sets a recurring review on an interval the change board agrees and runs each advisory match through a decision log. Each entry confirms whether the affected branch is in use, records the patch decision and its window, and links the upgrade. After any upgrade, the SBOM record and scanner inventory are updated and re-checked. Done when every matched advisory has a recorded decision and the stored SBOM matches the running version.

Evidence an SBOM-based review produces for auditors and buyers

An SBOM review is only as useful as the records it leaves behind. The cards below list the artifacts your own team should keep for each Collabora Online release in production, who signs each one off, and who owns it. These are records of your own review, not certificates issued by Collabora or DeployOpen.

SBOM for each deployed release

Keep the SPDX SBOM that matches each Collabora Online build you run, stored next to the image digest or package version it describes. Confirm that the SBOM was published for the exact release you deployed, since the SPDX 3.0.1 SBOM is published from 26.04 onward, and older branches may need a different source. Record where it came from and whether you verified it. Retain every release you ran during the period an auditor or customer may ask about. The platform engineering team owns the record, and the security lead signs off on acceptance.

Version inventory per environment

Maintain a list of the Collabora Online version running in each environment, including development, staging, production and any disaster recovery site. Include the packaging method (Docker image, system package or Kubernetes Helm release) and the date each version went live. Compare the inventory against the SBOM set each month so that no environment runs a component you have not reviewed. The operations team owns this record and the change manager signs off on updates.

Advisory-to-component match records

For each Collabora Online security advisory, record the date you received it, the components and versions it affects, whether your deployments are exposed, and the date you patched or accepted the risk. The 25.04 release notes show the kind of entry to match, such as the fix for CVE-2026-23623 in 25.04.7.5 released January 29, 2026. Keep the reasoning for any risk you accepted. The security operations team owns these records and the CISO signs off on accepted risks.

Patch and upgrade change records

Keep a change ticket for every patch and upgrade, listing the old and new versions, the test results on a copy of production, the rollback plan and the approval. Include the date of each change so the timeline matches your advisory records. Note any signing key rotation that affected RPM or DEB packages, so the package trust configuration can be reviewed later. The change advisory board owns these records and the service owner approves each one before production.

License review notes

Record the license of Collabora Online server code as MPL-2.0 and document how your team reviewed it, along with the licenses of other components in the SBOM. Note which edition you run, since CODE is a free edition that Collabora describes as not recommended for production, and which subscription terms apply to a supported deployment. Your legal or procurement team should confirm the obligations that come with each license. Legal owns the notes and the general counsel signs off.

Supplier questionnaire responses

Store the answers you collected from Collabora and from any integration or hosting provider in your chain, covering vulnerability disclosure, patch timelines, support periods and SBOM availability. Date each response and note which version of the questionnaire was used. Flag any answer that is unclear or missing so it can be followed up before the next review. The vendor management team owns these records and the procurement lead signs off after review.

What an SBOM cannot prove about your security posture

An SBOM tells you which components and versions are in a release. It does not tell you how those components are configured in your environment, who can reach them, which hardening controls are switched on, or whether a known vulnerability in a listed component can actually be exploited in your setup. A Collabora Online SBOM can show that a particular LibreOffice-derived component and version are present, but it cannot show that the WOPI allow list is restricted to your Nextcloud or other host servers, that proof keys are in use, or that the editor sits behind a reverse proxy with the TLS settings you expect. Those facts belong in your own configuration baseline and access review, and the SBOM should be read alongside them rather than treated as a substitute.

The 26.04 AI assistant shows why the inventory must be checked against the running configuration. According to the 26.04 release post, the assistant is optional across Writer, Calc and Impress, is off by default, and lets administrators choose whether the AI provider is hosted externally or on their own infrastructure. When it is enabled, the set of components that touch document data and network traffic changes, and the provider adds a dependency that the default-state inventory does not describe. Before relying on an SBOM for a review, confirm which optional features are enabled in your deployment, record each one in your change log, and request an SBOM or equivalent component list that reflects that configuration where the supplier can provide one.

A supplier's SBOM is one input to a supplier assessment, not the assessment itself. Pair it with the supplier's security advisory history, the timeliness of fixes such as the 25.04.7.5 release that addressed CVE-2026-23623, the signing key rotation process, and the support terms that define how long patches will arrive. Check the Collabora Online pricing page for what the Business and Enterprise plans say about long term support, signed security updates and the customer portal, and confirm the exact terms in writing with the vendor before you rely on them. Record which of these items you verified, when, and against which version, so the evidence still makes sense at your next review.

What Collabora Online and this page do not cover

The SBOM gives you component data, but it does not settle conformity, standards, patching duty, certification or production readiness. Each card below names a gap, the party responsible for closing it, and what to confirm before you rely on this page for a review.

CRA conformity assessment stays with the manufacturer

Conformity assessment under the Cyber Resilience Act is the manufacturer's obligation, not the obligation of an organization that deploys Collabora Online in its own infrastructure. Most products follow self-assessment under module A, while a notified body is needed for some class I, class II and critical products. Confirm with Collabora which product category and conformity route apply to the software you deploy, and keep your own records of how you configure and operate it.

Harmonized standards still in development

Request M/606 asks European standardization organizations for 41 harmonized standards, and their deliverables fall in 2026 and 2027. Until these standards exist in final form, you cannot fully map your controls to them. Track the status of each deliverable and ask Collabora which of them it plans to apply to its open-source releases.

SBOM is not a patching process

A Software Bill of Materials lists the components in a release, but it does not fix them or tell you that a fix exists. Vulnerability handling, security updates and reporting still require your own process: matching SBOM entries to advisories, applying point releases and recording the decision. Confirm how Collabora publishes advisories and signed updates for the branch you run, and who on your side owns each step.

Collabora's own certifications are not covered here

This page does not supply Collabora's certifications, attestations or audit reports for its company or its products. If a supplier assessment asks for them, request the current documents directly from Collabora and check their scope, date and the systems they cover. Do not assume that a certificate held by Collabora extends to your own deployment, configuration or hosting.

CODE is not for production

CODE, the free edition, is released roughly monthly as a rolling build and Collabora describes it as suited to testing, home use or small teams, not production. A supply chain review that depends on a fixed, supported release needs a supported Collabora Online subscription or a documented decision otherwise. Confirm which edition and branch your environment runs before you cite its SBOM in evidence.

DeployOpen prepares evidence, not audit results

DeployOpen can assemble SBOM outputs, version records, configuration evidence and supplier questions for your review. It does not issue audit reports, attestations or certifications, and it does not determine whether your product meets the Cyber Resilience Act. Ask your independent auditor, notified body or legal counsel to confirm which evidence they accept, and agree the deliverables in writing before work starts.

Questions buyers ask about Collabora Online SBOMs and CRA readiness

How much does a Collabora Online SBOM review cost?

Collabora's own pricing sets the cost of the software subscription: the Business plan costs 3 euros per user per month for up to 99 users, and the Enterprise plan for 100 or more users is quoted with volume discounts. The Business plan includes long term support, a service level agreement, signed security updates and customer portal access, so those recur with the subscription. DeployOpen does not publish a price list. A quote follows from the written scope, which depends on how many Collabora Online installations you run, how many branches and WOPI hosts are involved, how much evidence must be packaged for suppliers or assessors, and whether a CRA gap assessment is included. Ask for the review as a one-time line item and any ongoing monitoring as a separate retainer so you can see what recurs.

How long does a Collabora Online supply chain review take?

The duration depends on the written scope, which is agreed before work starts. The main drivers are the number of Collabora Online installations and the versions they run, since each branch may ship different evidence; the number of WOPI hosts and integrations that need mapping; how quickly your team can supply configuration, patch history and change records; and how many supplier questionnaires or assessor requests must be answered. Timing pressure also matters. Manufacturer reporting obligations under Article 14 of the Cyber Resilience Act apply from 11 September 2026, and most of the regulation applies from 11 December 2027. Ask for milestones covering evidence intake, SBOM mapping, advisory review, findings and handover of the review record.

What must we provide for a Collabora Online SBOM review?

The most useful inputs are the exact deployed version, a named owner for security advisories and a defined update window. Specifically:

the Collabora Online version and branch in each environment, such as the 25.04 or 26.04 line, with the installed point release;
the deployment method (system packages, Docker, or Kubernetes with the Helm chart) and the ingress in front of it;
a list of connected WOPI hosts and their versions;
change records for recent updates and your current patching process;
the person who reads Collabora advisories and decides what to do about them;
a window in which patches can be applied and tested;
any customizations, plugins or local build changes.

Without these, the review can only describe the software in general terms rather than the deployment you run.

Can our team run the SBOM and CRA review ourselves?

Partly. A capable team can use the SBOM and release notes to start, but a review needs more than those files. The SPDX 3.0.1 SBOM is published from 26.04, so confirm what evidence exists for any older branch before you plan around it. The Collabora Online release notes show the pattern to track: point releases fix vulnerabilities, and signing keys are sometimes updated for RPM and DEB users. Your team still has to map components to what you actually run, decide how quickly each advisory is applied, test document fidelity after updates and keep a record of each decision. The work can lapse after the first pass if no one owns it, so decide that owner before you start.

Does an SBOM alone satisfy the Cyber Resilience Act?

No. An SBOM is an input to CRA work, not evidence of compliance on its own. The regulation sets essential cybersecurity requirements for products in Annex I, and Part II of that annex lists eight vulnerability handling requirements for manufacturers. An SBOM helps with several of them, but it does not meet them by itself. Most products follow self-assessment under module A, while a notified body is needed in some cases. The obligations fall mainly on manufacturers who place products on the EU market. An organization that self-hosts Collabora Online for its own staff may not be the manufacturer, but that depends on whether it modifies the software or places it on the market under its own name. Confirm your role with legal counsel before you decide what evidence to produce.

What are the maximum CRA fines under Article 64?

Article 64 sets tiered maximums, and each tier is the higher of a fixed amount or a percentage of total worldwide annual turnover. Breaches of Annex I and of Articles 13 and 14 carry fines of up to EUR 15 million or 2.5%. Other listed obligations carry up to EUR 10 million or 2%. Incorrect or misleading information given to authorities carries up to EUR 5 million or 1%. These are maximums, not typical outcomes, and they apply to economic operators within the regulation's scope, so they matter most to manufacturers and distributors. Read the Regulation (EU) 2024/2847 text on EUR-Lex directly, because the tiers and scope rules use specific wording.

When do Cyber Resilience Act obligations apply to Collabora Online deployments?

Several dates apply, and which one matters depends on whether a product is new or already on the market. Chapter IV on notified bodies applies from 11 June 2026, and the Article 14 reporting obligations apply from 11 September 2026. The regulation applies in full from 11 December 2027. Products placed on the market before that date fall under the regulation only if they are substantially modified after it, but the Article 14 reporting obligations apply to all in-scope products whenever they were placed on the market. ENISA launched the initial operating capability of the CRA Single Reporting Platform on 11 September 2026, and the Commission published non-binding guidance on 27 July 2026. Confirm with counsel how each date applies to your deployment and to any product you build on it.

How DeployOpen scopes SBOM intake and CRA evidence work

DeployOpen treats the Collabora Online SBOM as an input to a written review, not a one-off file download. We agree what your organization needs from the SBOM, how it will be checked against your deployed versions, and which evidence your supplier and compliance teams will receive.

How we scope

Confirm which Collabora Online version and packaging (Docker, system packages or Kubernetes) your deployment actually runs.
Agree which SBOM uses, how it will be matched to deployed components, and who owns the vulnerability triage queue.
Record the supplier questions, CRA reporting contacts and internal review owners in a written scope before work starts.

How we build

Retrieve the SPDX 3.0.1 SBOM for your release and check it against the packages and images in your environment.
Set up a repeatable process to compare new Collabora Online point releases and advisories with the inventory.
Document how each finding is assessed, recorded and closed, with the evidence kept alongside your change records.

How we hand over

Deliver a written inventory mapping, triage procedure, and supplier assessment pack sized to the agreed scope.
Provide a CRA readiness note that explains which obligations apply to your role and which decisions remain with your legal team.
Walk your security and procurement staff through the process so the evidence can be reproduced without us.

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Ongoing SBOM refresh, advisory monitoring and evidence updates are available as a retainer.
Ask for a written quote based on your scope, and confirm details with Collabora and your legal advisers as needed.