Collabora Online security hardening guide

Why Collabora Online security hardening starts before the first document opens

Hardening a Collabora Online server means settling four controls before anyone opens a confidential file: which hosts may reach the server, how TLS is terminated, whether the admin console stays off the open network, and whether the server stays on signed packages that receive security fixes. A fifth decision, how downloads and watermarking are handled, follows from how sensitive the files are. These controls sit in different places. The WOPI host (for example Nextcloud), the Collabora server and the reverse proxy in front of it each hold part of the control, and a gap between them is easy to leave open. A security or platform lead should map each control to the component that enforces it before the rollout begins.

The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers and using the same protocol for the Collabora server URL as for the Nextcloud installation, preferably HTTPS. That advice only works if those addresses are stable and known. In many environments they are not. A server behind a NAT gateway, a load balancer that rewrites source addresses, or a pool whose members change during maintenance can send requests from addresses the allow list does not contain. Before configuring the allow list, confirm with your network team which source addresses the WOPI host will see from each Collabora node, including traffic passed through the proxy, and which addresses change during failover.

The edition choice belongs in the security baseline. Collabora describes CODE, the free Collabora Online Development Edition, as suited to testing, home use or small teams and not recommended for production. CODE is released on average once a month as a rolling release, so its update rhythm differs from a supported branch that receives point releases. For confidential files, ask the vendor or partner to state in writing which edition is planned, who provides signed security updates for it, and how quickly fixes reach your environment. Collabora's pricing page says the Business plan includes signed security updates, long term support and a service level agreement, so confirm the current terms there before relying on them.

Two more controls sit in the operating layer. First, keep the admin console off the open network by restricting it to a management network or named administrator addresses at the reverse proxy and firewall, then verify from outside your network that it does not respond. Second, stay on signed packages. Collabora publishes security advisories, and its 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623 and that package signing keys were updated for RPM and DEB users. Key rotations can require changes to your package trust configuration, so plan them with the upgrade calendar and test them in staging first.

Finally, decide how downloads and watermarking work for confidential files before users reach the editor. Nextcloud Office lets administrators limit which groups can use the editor and which groups can edit, so a read-only audience can be set up in the host configuration. Whether a given file can be downloaded, printed or watermarked depends on the WOPI host's policy and on the settings Collabora exposes, so confirm each behavior in a test environment with a sample file and record the result. Treat those answers as part of the security baseline, because a document that opens correctly for one group can still expose more than its owner intended.

Which components control access to a Collabora Online server

Access to a Collabora Online server is set by several components, each owned by a different team. Knowing which part controls which decision tells you where to apply each hardening step and who must approve changes.

The coolwsd server

The coolwsd process is the Collabora Online server that accepts WOPI requests, starts editing sessions and serves the browser editor. Its configuration decides which hosts are trusted, how sessions are handled and which features are enabled. Platform engineers usually own this layer, so check that its configuration file is readable only by the service account and that changes go through version control.

The WOPI host

The WOPI host, such as Nextcloud Office, decides which users can open a document, whether they can edit or only view it, and which files are sent to the editor. The Nextcloud administration manual recommends restricting WOPI requests to the Collabora server IP addresses and using HTTPS for the server URL. Application teams usually own group rules in the host, so confirm that each group rule matches your data classification.

The reverse proxy or ingress

The reverse proxy or ingress terminates TLS, forwards requests to coolwsd and sets the headers that the server relies on. It is also the point where you can block paths that should never be reachable from the internet, such as the admin console. Platform teams usually own it, so verify the certificate chain, the protocol versions offered and which paths are published. Routing must keep all users of one document on the same backend.

The admin console

The admin console is the web interface for viewing server state, managing settings and monitoring active documents. Anyone who can reach it can see session information and change configuration, so it needs its own access restriction. Platform teams typically own it. Confirm with the official documentation how the console is enabled and authenticated in your release, and limit network access to administrator networks only.

Package signing keys

RPM and DEB packages from Collabora are signed, and your servers trust those signatures when they install or upgrade. The 25.04 release notes record that package signing keys were updated for RPM and DEB users, so a stale key can block updates or leave you installing packages you have not verified. Platform teams own the key trust configuration. Check the signing key fingerprint against the vendor documentation before each key change.

Which hardening decisions to make before go-live

This table compares the main hardening choices for a Collabora Online server: how to restrict WOPI requests, where TLS ends, how the admin console is reached, and which edition to run. Read each row for when the option fits and what it asks of your team after go-live.

Decision	Option and when it fits	Operational cost
WOPI allow list	Fixed host IP addresses: fits a small, stable set of Nextcloud or other WOPI host servers that rarely change.	Someone must update the IP list whenever a host node is added, replaced or moved, or editing breaks for those users.
WOPI allow list	Network segment restriction: fits hosts on a dedicated subnet or private network where the Collabora server can trust the whole segment.	Requires network design and change control with the infrastructure team, and the segment boundary must be reviewed when hosts move.
WOPI allow list	Host-issued access tokens alone: fits environments where the host network cannot be fixed, with tokens as the main control.	Less network-level defense, so token handling, expiry and host hardening carry more weight and need evidence in your review.
TLS termination	Terminate at a load balancer: fits teams that manage certificates centrally and where the internal hop sits on a segment you control.	Certificate renewal stays in one place, but the internal path must be verified as private, and the proxy configuration must be kept aligned with the server.
TLS termination	End to end encryption to the Collabora server: fits strict internal encryption requirements or shared networks where the internal hop is not trusted.	More certificates to issue, rotate and monitor on each node, and the Nextcloud and Collabora URLs must use matching protocol settings.
Admin console exposure	Restricted network or VPN access: fits most production servers, where administrators reach the console only from named management networks.	Requires maintaining network rules and VPN accounts, and administrators need a documented access path for incidents.
Admin console exposure	Admin console disabled after setup: fits deployments where configuration is managed through files and changes go through a pipeline.	Changes must go through configuration management, and troubleshooting depends on logs and file review rather than the console.
Edition choice	CODE, the free rolling edition: fits testing, home use or small teams, as Collabora itself does not recommend CODE for production.	No license fee, but your team must track monthly rolling builds and absorb unplanned upgrades and security response on its own.
Edition choice	Supported subscription: fits production systems that need signed security updates, long term support and a service level agreement.	Recurring per-user subscription fees, plus a patch process that applies Collabora's point releases and signing key updates promptly.

How to harden a Collabora Online server step by step

This sequence hardens a Collabora Online server in the order each control depends on the last: confirm the version, restrict who can reach the server and how, then control who can edit documents. Each step closes with a test you can repeat and record as evidence for a security review.

Confirm the edition and version in use
The platform engineer records whether the server runs the free CODE image or a Business or Enterprise subscription build, along with the exact version and branch. Compare that version with the release notes for its branch and list any security fixes it lacks. CODE is described by Collabora as suited to testing, home use or small teams, so confirm the edition matches the production role before go-live. Security advisories are published per release, so an unpatched version is the first item to fix. The step is done when the version appears in the change record and every later check is run against that exact version.
Restrict WOPI requests to Collabora server addresses
On the WOPI host, set the allow list so only the IP addresses of the Collabora servers can send WOPI requests, as the Nextcloud administration manual recommends. Get the outbound addresses of each coolwsd server or load balancer from the network team first, because a missing address breaks editing for that server. Then send a WOPI request from an unlisted address, such as a workstation on a user network, and confirm the host refuses it. The step closes when the unlisted request is refused and a request from a listed Collabora address succeeds.
Set the Collabora server URL to HTTPS
In the Nextcloud Office settings, set the Collabora server URL to use the same protocol as the Nextcloud installation. The Nextcloud administration manual recommends HTTPS for this URL, and the host name in the URL must match the certificate presented by the proxy. A protocol mismatch or a host name mismatch blocks the editor in the browser. Save the setting, then open a test document in a browser and watch the developer console for mixed-content or certificate warnings. The step is done when the editor loads over HTTPS with no mixed-content errors and the saved URL matches the host name on the certificate.
Terminate TLS and verify the certificate chain
Configure the reverse proxy or load balancer that terminates TLS in front of coolwsd with a certificate from an authority your users trust, and install the intermediate certificates so the server sends the full chain. From an admin workstation, run a chain check against the public host name, for example with openssl s_client, and confirm the verification result is successful and the host name matches. Also confirm that the WebSocket connections used by the editor pass through the proxy without being cut off. The step is done when the chain verifies from a client that trusts only the public roots and the editor opens without certificate prompts.
Restrict the admin console to administrators' network
Limit access to the coolwsd admin console to an administrators' network segment or a jump host, and block the admin path at the proxy for every other source. Store the admin console credentials in a secrets manager and rotate them after any change in administrative staff. Verify from a workstation on a user network that the admin console URL is unreachable, meaning the connection is refused or no console page loads. Then verify from the administrators' segment that the console loads and asks for sign-in. The step is done when both results are recorded in the change record.
Apply group rules for editing and use
In the Nextcloud Office settings, set the group limits described in the Nextcloud administration manual so you control which groups may use the editor and which groups may edit documents or only view them. Map each group to a business role, keep a view-only group for users who need read access, and leave out groups that have no business need. Test with one account from each group by opening a shared file and checking whether the editing controls appear. The step is done when the view-only test account cannot enter edit mode and an editing account can.
Confirm signed package sources
Confirm that the packages used to install or update Collabora Online come from Collabora's repositories and that the installed RPM or DEB packages verify against the signing keys Collabora publishes. The 25.04 release notes record that package signing keys were updated for RPM and DEB users, so check that each host holds the current key and that any retired key has been removed. Run the package manager's signature verification on the installed package and record the result. The step is done when every server's package verifies and the source and key used for each host are documented.

Hardening controls for the WOPI link, TLS and admin access

Most of the exposure in a Collabora Online deployment sits at its edges: which WOPI hosts can reach the server, how traffic is encrypted, who can reach the admin console, and how the software that runs it is kept trusted. The cards below cover those edges in the order a reviewer usually checks them, with the points to confirm for each in your own environment.

WOPI host allow list scope

The WOPI allow list defines which hosts may ask the server to open documents. Limit it to the hostnames or addresses of the platforms you actually run, such as your Nextcloud instance, and remove test or legacy entries. Nextcloud's administration manual recommends restricting WOPI requests to the Collabora server addresses. Confirm the exact allow list setting and syntax against the Collabora documentation for your release before you change it.

HTTPS-only server URLs

The Collabora server URL configured in the WOPI host should use the same protocol as the host itself, and Nextcloud's administration manual prefers HTTPS. Check every place the URL appears, including the host's office settings, reverse proxy configuration and any internal callback addresses, so that no plain HTTP path remains. A mismatch often surfaces as blocked mixed content or failed document loads, which is a signal to review the whole chain rather than to relax the check.

Certificate management and renewal

Assign ownership for the TLS certificate on the Collabora hostname, record its issuer, expiry date and the systems that install it, and automate renewal where your certificate authority supports it. Make sure the certificate chain is complete at the proxy, because incomplete chains break some clients intermittently. Test renewal in a staging environment before the expiry date arrives, and confirm that the WOPI host trusts the certificate authority used.

Admin console network restriction

The Collabora admin console is a management interface and should not be reachable from the public internet or from general user networks. Restrict it to a named administration network, a VPN or a bastion host, and confirm that the proxy rules block it on every public listener. Verify the restriction from outside the allowed network with a simple request, and record the test result as evidence for your review.

Admin credential handling

Admin console credentials should be unique to this deployment, stored in your secrets manager, and rotated under a written schedule. Avoid placing them in container images, shell history, configuration files committed to version control or chat tools. Review who holds the credentials, remove access when staff change roles, and confirm the method for changing the password in the release you deploy.

Package signing keys and package sources

Install packages only from the official Collabora repositories and verify them against the trusted signing keys for your distribution. The Collabora Online 25.04 release notes record that package signing keys were updated for RPM and DEB users, so refresh the trusted keys as part of each patch cycle and not only at first install. Pin the source you use, keep a record of the key fingerprints you trust, and confirm the current procedure in the release notes before you patch.

How to limit downloads and watermark confidential files

Confidential documents often need more than edit rights. Some need downloads blocked, copying or printing restricted, or a visible watermark that identifies who opened the file. These controls do not come from Collabora Online alone. They depend on what the WOPI host asks for when it opens a document, on what the Collabora server honors for the version you run, and on whether the control applies to every path a user can take into the editor. Decide the requirement first, then confirm which controls your exact combination of host and server supports before you promise them to the business.

Start with the documentation for your Collabora Online version and the Nextcloud Office or other host documentation for the WOPI permissions it sends. For each candidate control, confirm three things: whether it exists in that release, where it is configured (on the WOPI host, on the coolwsd server, or in both), and whether it holds for every editing path. Editing paths include opening from the file browser, opening from a share link, opening through a mobile or desktop client where supported, and any direct WOPI access your host exposes. A control that applies only to the default path is a gap, and the gap should be recorded in your risk register rather than hidden in the configuration notes.

Group-based access in Nextcloud Office is a useful first layer. Administrators can limit which groups may use the editor at all and which groups may edit rather than only view. Restricting edit rights reduces how many people can change or copy confidential content, but it does not stop a user who has view access from downloading, printing or copying what they see. Treat group rules as reducing exposure, and treat download, copy, print and watermark controls as separate requirements that need their own evidence.

Do not assume any control works until someone proves it. Create a test account that belongs only to the most restricted group, open a representative confidential file through each path your users will use, and try to download, print, copy and export it. Check that the watermark appears on screen and in any printed or exported output where the control claims to cover it. Repeat the test after every Collabora Online point release, host upgrade or change to the permission mapping, because a control that held in one version can change in another. Keep the test script, the account used, the versions tested and the results, since an auditor or security reviewer will ask for them.

Where a control cannot be confirmed for your version or path, plan a compensating measure and say so plainly to the data owner. Options include limiting confidential content to a separate host instance, restricting access by network location or device, or excluding the most sensitive documents from browser editing altogether. Ask Collabora and your host vendor which controls are supported, which are configured by you, and which are not offered, and get those answers in writing before go-live. Accurate statements about what the platform does and does not block protect both the data and the people who signed off on the rollout.

What drives the effort and cost of hardening

This table lists the factors that change how much work hardening a Collabora Online deployment takes, how each one moves the scope, and how to keep it contained. Read it when scoping a quote, since the same server can need a light or a heavy hardening effort depending on these inputs. The main takeaway is that standardizing the allow list, consolidating environments and agreeing the evidence scope early usually keeps both one-time and recurring work manageable.

Driver	Why it changes effort or cost	How to keep it down
WOPI hosts and environments	Each host needs its own allow list entries, TLS settings and test cases, and each environment (development, staging, production) repeats the work.	Consolidate hosts where the business allows, and generate allow list entries from one infrastructure code source reused across environments.
Number of Collabora servers or pods	Every coolwsd server or Kubernetes replica needs the same configuration, patch cycle and verification, and more nodes widen the IP list to maintain.	Keep server configuration in versioned templates or Helm values so new nodes inherit hardening without manual steps.
Network topology	A flat network needs more controls at the host level, while segmented or air-gapped designs add routing, egress and certificate work that must be designed and tested.	Agree the topology before hardening starts, and place Collabora in a segment that only the WOPI host and users can reach.
Groups needing differentiated edit and view rights	Each group split means more host-side configuration to test, plus role checks on both the host and the editor.	Limit the number of groups to the real business roles, and document the mapping in one place the host administrator owns.
Confidential file classes with download or watermark controls	Download restrictions and watermarking depend on what the WOPI host enforces, so each file class needs its own rules and tests.	Define a small set of classification levels and apply controls per level rather than per file type.
Compliance evidence required	Assessors may ask for configuration records, access logs, patch records and change history, and each item must be produced and retained.	Agree the evidence list before work starts and generate it from configuration and logs during routine operation.
Recurring operations	Patching signed packages, rotating keys and TLS certificates, and maintaining the IP allow list continue after handover and add to ongoing support cost.	Automate patch and certificate rotation, and review the IP list on a set schedule tied to change management.
Cost components and who is paid	Scoping, configuration, testing and handover are usually billed to the implementation partner as fixed-scope work, while patching and key rotation may be internal or retained.	Ask each quote to split one-time work from recurring items and name who performs each step.

How to test that Collabora Online refuses what it should

A hardened Collabora Online server is only proven when each control is shown to refuse the requests it should refuse. Start with the WOPI allow list. Send a WOPI request to the coolwsd server from an address that is not on the list, and confirm that the request is refused. Then send the same request from an address that is on the list and confirm that it succeeds. The second step matters because a refusal can come from a broken network path or a misconfigured proxy rather than from the allow list itself. Record both results with the source address, the time and the response code.

Next, test the server URL and transport. The Nextcloud administration manual recommends using the same protocol for the Collabora server URL as for the Nextcloud installation, preferably HTTPS. In a test environment, configure a plain HTTP server URL in the WOPI host and check whether the host accepts it. If it does, record that as a finding and decide whether the host setting, the reverse proxy or both must change. Then test the admin console. From a user network and from a VPN range that users can reach, attempt to open the console path and confirm that the connection is refused or times out. Confirm the exact console path and its access settings for your release in the official documentation before running this test.

Test the permission model with one account per group. A user outside the editing group should see view-only access or no access, as you configured it in the WOPI host. Nextcloud Office lets administrators limit which groups can use the editor and which groups can edit, so test each combination you intend to allow. For a restricted account, attempt each blocked action: download, copy, and any other action your policy blocks. Note whether each refusal is enforced by the server or only by the browser interface. Browser-side controls can be bypassed, so a control that is only visible in the interface should be recorded as a weaker result than one the server refuses.

Confirm the version and package signatures before you trust any test result. Check the running version against the Collabora Online release notes for your branch. The 25.04 branch was still receiving point releases in 2026, with 25.04.13 released on September 21, 2026, so confirm whether your server is on that point release or an earlier one. For RPM and DEB installs, verify the package signatures against the signing keys Collabora publishes. The 25.04 release notes state that package signing keys were updated for RPM and DEB users, so check that your repository key is current. For Docker, compare the image digest you deployed with the digest from the source you trust. CODE is not recommended for production, so confirm which edition you are testing.

Record every result as evidence in a form an auditor or security reviewer can follow. For each test, keep an identifier, the control it covers, the date, the tester, the expected result, the actual result, the Collabora version and the relevant request and response with secrets and personal data removed. Add screenshots for interface-level checks and store the records with your change tickets. Failed tests should stay in the record with the fix and the retest. DeployOpen prepares and tests these controls and documents the evidence, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies carry out those assessments and decide what the evidence supports.

How hardening differs for single node, Kubernetes and air-gapped deployments

On a single node, the server, the reverse proxy and the admin path all sit on one host, so the hardening surface is small and easy to review. The main change is that the WOPI allow list usually holds one entry, the address of the host that serves the WOPI requests, and the admin console is reached through one access path. What stays the same is the core baseline: TLS on every hop, the admin console kept off public networks, and signed packages applied on a regular schedule.

The points to plan for on a single node are:

One allow list entry: Confirm the exact address the WOPI host uses when it calls the server, including any NAT or proxy translation, and add only that address.
One admin access path: Restrict the admin console to a named management network or a VPN, and remove any public route to it.
Single host outage risk: If the host fails, all document editing stops. Document the recovery steps and the expected downtime with the business owner.
Patch windows: Because there is no second node to take traffic, plan updates in a maintenance window and test the restart before applying changes.
Log retention: Keep reverse proxy and server logs off the same disk as the application data so a disk fault does not remove the evidence you need.

Before go-live, check that the allow list matches the observed source addresses in the logs, and that the admin console cannot be reached from a user network.

What to monitor, patch and document after go-live

The first routine is knowing when Collabora changes something that affects your server. Track the security advisories Collabora publishes for Collabora Online and assign one owner to read each one when it appears. The 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623 and updated the package signing keys used for RPM and DEB installs. A routine package update may therefore depend on the new key, so confirm that your repository and signature checks still work before the next patch window. Plan point releases for the branch you run. The 25.04 branch was still receiving point releases, with 25.04.13 released on September 21, 2026, so a fixed branch gives your team a predictable test cycle. Ask Collabora how long your branch will continue to receive fixes.

Some controls drift quietly after go-live, and the WOPI allow list is the clearest example. The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers. Every change to a Collabora server address, load balancer, NAT gateway or ingress controller therefore needs a matching allow list change in the same change record. Review the list after infrastructure work, not only after an incident. Keep the Collabora server URL on the same protocol as the Nextcloud installation, preferably HTTPS. Certificates need the same discipline. Track expiry dates for the TLS certificate on the reverse proxy and for any internal certificates used between the host and the server, rotate them before they expire, and confirm the new chain loads correctly. Review who holds admin console access on a schedule your security team sets, and remove accounts that no longer need it.

After every upgrade or point release, repeat the checks that protect confidential files. Download and watermark settings are the controls most likely to change through a configuration reset or a template update, so do not assume they survived. Use a short written test set with a sample confidential file and a view-only test user. Confirm that the download restriction still blocks export where you set it, that the watermark appears on screen and in the expected places, and that a user in a view group cannot switch to edit mode. Repeat the Nextcloud group checks as well, because the rights to use the editor and to edit are set on the host side. Record each result with the version tested and the name of the person who ran the test, so the next upgrade starts from recorded evidence.

Patch planning depends on the edition you run. The Business plan includes signed security updates and customer portal access, which gives your team a formal channel for fixes and a defined place to retrieve them. CODE is a rolling release, published on average once a month, and Collabora describes it as suited to testing, home use or small teams while advising against production use. A rolling build has no fixed branch to pin, so each new release becomes a change to test against your settings before it reaches users. Before go-live, ask which edition gives you the update path your change policy requires. Then keep a hardening record that lists configuration settings, installed versions, signing and certificate details, test results and a named owner for each item. Review the record at every upgrade so it matches the server that is actually running.

Questions teams ask before hardening Collabora Online

Can our own team harden a Collabora Online server without a partner?

Yes, if your team can change server configuration, reverse proxy rules, TLS settings and host access controls, and can test each change against live document editing. Hardening Collabora Online is mostly configuration work: restricting which WOPI hosts may call the server, terminating TLS correctly, limiting access to the admin console and keeping packages current. The main risk sits in testing. A change that blocks a WOPI host or breaks the WOPISrc request path can stop editing for users without an obvious error. Teams without anyone who has run a reverse proxy and a document service in production often find that a fixed-scope engagement, or a written runbook followed step by step, reduces that risk. Start with an inventory of your WOPI hosts, ingress paths and admin access before you decide.

What does hardening Collabora Online ask of our network, identity and host teams?

Hardening needs three groups of administrators working from one plan. Network administrators control the firewall rules and load balancer routing that decide which hosts can reach the Collabora server and how requests reach it. Identity administrators own sign-in on the WOPI host, the group rules that decide who can view or edit, and any single sign-on configuration on the host side. Host administrators manage the operating system or container platform, exposure of the admin console, logging and the package update process. Each group needs to review and approve changes in its own area. At least one person should understand how a request travels from the user's browser through the WOPI host to the Collabora service. If one of these groups is missing, the work usually stalls at the first change that needs its approval.

How is the cost of hardening Collabora Online calculated?

The cost follows the scope you agree in writing, not a single fixed figure. DeployOpen does not publish a price list, so a quote comes from the written scope. The main drivers are the number of WOPI hosts and environments to cover, how many network paths and ingress layers need review, whether identity integration on the host side is included, how much testing against your own document types is required, and whether you need documentation or evidence for an internal or external compliance assessment. Ask for a quote that lists each item as a separate deliverable, marks which items are one-time work and which recur, and states what your team must provide. Licensing is a separate line. The Business plan is listed on Collabora's pricing page at 3 euros per user per month for up to 99 users, and that fee is paid to Collabora.

Can we harden the free CODE edition for production use?

Collabora does not recommend CODE for production. Its product page describes CODE as suited to testing, home use or small teams, and CODE is released on average once a month as a rolling release. A rolling build changes often, so it gives you no stable branch to plan around. Hardening CODE does not change that recommendation, so decide the edition first and the controls second. The Business plan adds long term support, a service level agreement, signed security updates and customer portal access, according to Collabora's pricing page. Ask any partner to state in the quote which edition the work covers. Treat a hardened CODE server as a test environment unless you have accepted that trade-off in writing after reviewing Collabora's terms.

How often does Collabora publish security patches for Collabora Online?

Collabora publishes security advisories for Collabora Online, and the update process matters because a server that receives documents from many users is exposed to any flaw in the release you run. The 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623 and that package signing keys were updated for RPM and DEB users. That is one documented example, and it does not describe a fixed schedule. The 25.04 branch continued to receive point releases into 2026, with 25.04.13 released on September 21, 2026. Read the release notes and advisories for the branch you run, verify package signatures after any key change, and confirm with Collabora which update channel your edition includes. Build a patch window into your operating plan so security releases are tested and applied on a known schedule.

How does fixed-scope hardening differ from ongoing support retainers?

A fixed-scope engagement delivers a defined set of hardening work, with scope, deliverables and timelines agreed in writing before work starts. It ends when those deliverables are accepted, and the result is a configured server, documentation and any evidence you asked for. Ongoing support is a separate arrangement, usually a retainer, that covers work after go-live, such as applying point releases, reviewing advisories, re-testing after changes to the WOPI host and correcting configuration drift. DeployOpen offers both. Most engagements are fixed-scope, and support, upgrades and continuous testing are available as retainers. Hardening done once goes out of date as releases and host configuration change, so ask whether the quote includes a handover that lets your team run the controls, a retainer, or both, and what each option costs to keep running.

Which WOPI allow list settings should we restrict first on a Collabora server?

Restrict WOPI access to the hosts you control and the IP addresses you have confirmed. The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers, and it recommends using the same protocol for the Collabora server URL as for the Nextcloud installation, preferably HTTPS. Start there, then check each allowed host against your inventory, including any test or staging WOPI host. Also review group rules on the host. In Nextcloud Office, administrators can limit which groups may use the editor and which groups may edit or only view. Test by opening a document as a user from each group, and confirm that unauthorized requests fail. Record the allow list and its owner so that every change passes through review.

How DeployOpen scopes, hardens and hands over Collabora Online security work

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, so the Collabora Online server, its WOPI host connection and its admin access stay under your control. Each hardening control is agreed in writing before work starts, with its test and its owner named. Engagements are fixed-scope, and ongoing support is available as a retainer.

How we scope

Inventory the WOPI hosts, users and file types that reach the Collabora Online server
Agree in writing which hardening controls are in scope, including allow lists, TLS, admin console and downloads
Confirm with the vendor whether your chosen edition supports download restriction and watermarking before committing scope

How we build

Restrict WOPI requests to Collabora server addresses and serve both sides over HTTPS, per the Nextcloud admin manual
Terminate TLS at a reverse proxy you control and keep the admin console off public networks
Apply signed point releases from Collabora's packages after testing them in a staging environment first

How we hand over

A hardening baseline document listing each setting, its reason and where it lives in your configuration
Test evidence for allow list rejections, TLS grades and access tests, kept for your assessors
A runbook for updates, security advisory review and rollback, with named owners on your side

How we support

Ongoing support can cover advisory review and point release application under a retainer
Periodic security testing of the hardened server, available as a continuous testing retainer
Separate one-time hardening work from recurring costs in every quote, including any Business plan seat fees

Collabora Online security hardening