Collabora Online for defence and classified networks

Why Collabora Online in defence and classified networks needs an isolated-network plan from day one

Collabora Online fits an isolated network if you run it yourself. It is a self-hosted, browser-based editor for documents, spreadsheets and presentations, connected to a host platform through the WOPI protocol, and its server code is licensed under MPL-2.0. What changes compared with a connected deployment is everything around the editor: every container image, package, font and signing key has to arrive by a controlled route, every update has to be verified before it crosses the boundary, and nothing can depend on an external lookup at runtime. The free CODE edition is a rolling release that Collabora does not recommend for production, so a classified or defence deployment should be planned around a supported Collabora Online release and a support contract that covers it.

The hard parts are not the editor. They are offline delivery of the Collabora Online packages or images and their dependencies, verification of each update against the vendor's signed releases before it is imported, and the routing and sizing decisions that determine which hosts and networks are allowed to talk to the editing servers. Accreditation evidence sits across all of these: a record of what was transferred, who approved it, how its integrity was checked, and which WOPI hosts are permitted. Confirm with Collabora and your accreditor which Collabora Online release, packaging format and signing key process fit your authorization boundary before you choose a deployment method, because those choices decide how much of the transfer and verification work you own.

Start the plan before the first server is built. Decide which host platform will call Collabora Online, such as Nextcloud, and which network segments need access, then write down the WOPI allow list, the TLS arrangement between the host and the editing servers, and the process for importing each update. Use the Nextcloud administration manual's guidance on restricting WOPI requests to known Collabora server addresses as a starting point, and test that the restriction holds before users arrive. Teams that defer these decisions usually find that the first update cycle, not the first deployment, is where the isolated-network design gets tested.

Which defence and isolation requirements shape the Collabora Online build

This table lists the energy, federal contracting and criminal justice requirements that most often reach a Collabora Online build, and what each one means for offline packages, key lengths, WOPI allow lists and scanning cadence. Each requirement applies only through the authority, contract and system boundary your organization or your customer operates under, so confirm applicability with your assessor or contracting officer before designing around it. Read the right-hand column as build decisions to record for assessors.

Requirement	What it asks for	What it means for the Collabora build
NERC CIP-005-7, remote access	Remote access to high and medium impact BES Cyber Systems passes through an Intermediate System, encrypted and protected by MFA, with vendor sessions detectable and disableable.	Applies only to BES Cyber Systems. Route vendor support sessions to editing servers through the intermediate system and log session start and end.
NERC CIP-013-2, software integrity	Procurement processes address verifying the integrity and authenticity of vendor software and patches.	Check signatures and image digests for each package, image and update before it crosses the boundary. Verify signing keys against Collabora's published key updates.
32 CFR 2002.14(h)(2), CUI on non-federal systems	Agencies apply NIST SP 800-171 to CUI on non-federal systems unless the CUI authority prescribes other safeguards.	Collabora servers, logs and temporary document storage on non-federal systems fall under the 800-171 requirements. Confirm the CUI category's authority first.
32 CFR 170.17(c)(5), CUI in cloud services	CMMC Level 2 contractors may store or process CUI in a cloud service only if it is FedRAMP Moderate or equivalent.	If the Collabora host runs in a cloud service, confirm that service's FedRAMP status. On-premises servers stay inside your assessed scope.
CJIS v6.1, encryption	FIPS 140-3 validated modules or AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations.	Document the FIPS 140-3 status of TLS libraries and storage encryption. Use AES-256 keys for encrypted volumes holding documents.
CJIS v6.1, vulnerability scanning	Vulnerability scanning at least monthly across the systems that handle CJI.	Scan Collabora hosts, containers and offline update media at least monthly, and record the findings against each package version.
Nextcloud admin guidance, WOPI access	Restrict WOPI requests to the Collabora server IP addresses and use the same protocol, preferably HTTPS, for both URLs.	Set the WOPI allow list to the Collabora server addresses and keep the Nextcloud and Collabora URLs on HTTPS.

Choosing between an air-gapped install and a restricted-network install

A fully air-gapped enclave has no route to the internet or to any update service, so every container image, system package and signing key arrives on approved media after it has been checked outside the boundary. The Collabora Online server runs from an internal registry or package repository, and the Helm chart values or Docker configuration point at that internal source. The release you run is the release you last imported, so patch latency is set by the transfer cycle.

Transfer path: download the collabora/code image or the RPM or DEB packages in a staging zone, scan them, record hashes and carry them in on approved media.
Chart mirroring: rewrite the image references in the Helm chart to the internal registry, and copy every referenced image, including sidecars and ingress dependencies, not only the main image.
Update cadence: each point release needs a complete import cycle, so the interval between security fixes and your deployment depends on how often the boundary admits media.
Key trust: import and verify package signing keys inside the enclave, since Collabora's signing key updates for RPM and DEB users must reach you through the same path as the packages.

Before committing to this model, ask your authorizing official whether the import process is accepted for signed security updates, and confirm that the manual replica counts and WOPISrc-based routing described in the Collabora Online Helm chart README are reflected in your runbooks, since they apply in every model.

Configuration decisions that matter in isolated defence networks

In an isolated network, most Collabora Online risk sits in a handful of configuration choices: who can reach the server, how traffic is protected, who may edit, how the cluster routes sessions, how much capacity each pod gets, and whether optional AI features are on. Each card below is a decision to make and verify before the first document is opened.

Restrict WOPI host allow lists

The Collabora server should accept WOPI requests only from the Nextcloud or other host addresses you have approved. The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers, which is the reverse direction of a plain host allow list, so confirm which side of the connection your version enforces. Review the list whenever a host is added, moved or retired, and record who approved each entry.

Match protocol between host and server

Use the same protocol for the Collabora server URL as for the Nextcloud installation. The Nextcloud administration manual prefers HTTPS. A mismatch between HTTP and HTTPS is a common cause of connection failures and tends to surface late, after users have started working. Test the full path from the host to the server and back, including TLS certificate chains issued by your internal certificate authority, before opening the service to users.

Limit who can edit in Nextcloud Office

Nextcloud Office lets administrators limit which groups can use the editor and which groups can edit rather than only view. In a defence environment, map these groups to your existing access roles, so that read-only access for reviewers and partners is enforced by the platform rather than by convention. Test each role with a real account before go-live and confirm that group changes in your directory propagate as expected.

Pin replicas and route by WOPISrc

The official Helm chart disables horizontal pod autoscaling because scaling breaks collaborative editing and copy and paste, so replica counts are set by hand. The load balancer must route by the WOPISrc parameter so every user editing a document reaches the same pod. Choose between Nginx, HAProxy and OpenShift Router ingress based on what your isolated platform already operates, and test concurrent editing on the same document after every change.

Set pod resource limits deliberately

The Helm chart recommends production limits of 8 CPU cores and 8000 MiB of memory per pod, with requests of 4 cores and 6000 MiB. Treat these as starting values to validate against your own concurrency and document sizes, not as a sizing result. Confirm that your cluster nodes can satisfy the requests without eviction, since in a fixed-capacity enclave a failed scheduling decision cannot be fixed by adding capacity quickly.

Keep the AI assistant off

Collabora Online 26.04 adds an optional AI assistant across Writer, Calc and Impress. It is off by default, and administrators choose the provider and whether it is external or self-hosted. For a classified or isolated network, keep it disabled unless a reviewed, self-hosted provider is approved for the data involved. Record the setting in your configuration baseline and check it after each upgrade, because a new release can change defaults.

How a phased Collabora Online rollout moves through an isolated enclave

The sequence moves Collabora Online from an approved boundary and offline artifact set into a pilot, a format check, and a staged cutover with a rollback path, so each phase closes with evidence the enclave owner can accept. Confirm your own approval gates before the first phase starts.

Review the boundary and classify the data
Start by agreeing the enclave boundary, the network paths that exist or are forbidden, and the classification levels of documents the editor will touch. You provide the security authority's boundary diagram, the data owners who label content, and any policy that governs cross-domain transfer. DeployOpen maps the planned Collabora Online components, their ports and their dependencies (for example the WOPI host, the storage backend and the identity source) against that boundary. The step is done when the security authority signs off on which components are in scope and which document categories are excluded from the pilot.
Build and verify the offline artifact set
Assemble every container image, package, font and configuration file on a connected build host, then record checksums and verify publisher signatures before anything crosses the boundary. You provide the transfer media process, the approved software intake procedure and the internal registry or package repository inside the enclave. DeployOpen produces a manifest listing each artifact, its version and its verification result, and checks that the enclave can install from that manifest without internet access. Confirm how your supply chain procurement process records software integrity checks, since that record is the evidence an assessor will ask for.
Run a pilot on a non-sensitive corpus
Install the editor in a pilot tenant and open only documents from a corpus that carries no classified or controlled content. You provide a small pilot group, named administrators and the non-sensitive sample documents, including representative Microsoft Office, OpenDocument and PDF files. DeployOpen configures the WOPI integration with the host platform, applies the allow list and confirms that sessions, saves and locks behave as expected under a few concurrent editors. The pilot is complete when the operators have logged a known-issues list and the security authority has reviewed the access logs from the pilot.
Test format fidelity against real documents
Compare how documents render, edit and save in the editor against the originals in the sending application, using a fidelity test set agreed with the document owners. You provide the test set, the list of templates and macros your users depend on, and the acceptance criteria for layout, tables, fonts and tracked changes. DeployOpen runs the round-trip tests, records each difference and classifies it as acceptable, workaround or blocker. The step closes with a signed fidelity report that tells document owners which formats and templates are safe for the next stage.
Enable groups in stages with edit rights
Open the editor to one group at a time, first to view and then to edit, using the group restrictions the host platform provides. You provide the group list for each wave, the approvers for each expansion and the rule that decides who may edit classified or controlled material. DeployOpen sets the group permissions, monitors session and error rates for each wave and confirms that users outside the approved groups cannot launch the editor. Each wave is complete only when the approver records acceptance and the monitoring shows no unresolved access or data handling issues.
Cut over with a tested rollback path
Switch the default editing path for the remaining users, with the previous method kept available until the rollback window ends. You provide the change window approved by the enclave owner, the named decision maker for rollback and the list of documents that must be checked after cutover. DeployOpen executes the switch, runs the rollback procedure in a rehearsal beforehand and keeps configuration and backup snapshots from before the change. The cutover is done when the post-change checks pass, the rollback has been rehearsed successfully, and the operations team has handed over runbooks and the patch process for future Collabora Online updates.

How classification labels and mobile editing on secured devices change the design

The supplied facts do not establish native classification label support in Collabora Online, so label handling has to be confirmed before it is designed in. Collabora Online receives documents through the WOPI protocol from a host platform, and the host decides who sees a file, who may open it and which sensitivity marking travels with it. Ask the host vendor whether its sensitivity labels, marking rules and access policies are enforced when a document is opened in the Collabora editor, and whether the label is preserved when the file is saved back. Ask Collabora the same questions about what the editor itself reads, displays, rewrites or strips. Until both answers are in writing, do not promise label-aware editing to the accrediting authority or to users, and record the open questions as design risks.

Mobile and secured-device access is mostly a question of the managed browser and the device posture, not the editor. Users on managed devices reach Collabora Online through the browser that the host platform serves, so the design should define which devices, browsers and network paths are permitted, whether sessions must come from an approved managed endpoint, and how session timeouts and copy or download restrictions are handled in the host. Confirm with the host vendor which of these controls it can enforce at the WOPI boundary and which must be handled by your endpoint management tooling. Test the editor on the exact browser builds you will allow on managed devices, since an unsupported build is a common source of failures that look like security problems.

Restricting who can edit is the control most likely to need design work. In Nextcloud Office, administrators can limit which groups can use the editor and which groups can edit rather than only view, so a classified workspace can separate read access from write access by group. Map each group to a documented need, for example a review group with view-only access, and confirm that the host applies the same restriction to every route into the document, including shared links and mobile clients. Record who approves changes to these group settings, and review them on the same cadence as your access certifications.

How security patches reach an offline Collabora Online estate

How do point releases reach the Collabora Online 25.04 branch?

The 25.04 branch receives numbered point releases, and it was still receiving them in 2026. According to the 25.04 release notes, the branch first shipped as 25.04.2.3 on June 19, 2025, and 25.04.13 was released on September 21, 2026. Security fixes arrive inside these point releases. For example, 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623. An offline estate therefore needs a repeatable process for receiving each point release, not a single installation project. Read the 25.04 release notes for each new entry before you approve it, and confirm with Collabora which point release is current before you schedule a change window.

Did the signing keys for RPM and DEB packages change?

Yes. According to the 25.04 release notes, package signing keys were updated for RPM and DEB users. A mirror that trusts only the old key will reject newer packages, and a team that imports keys without checking them could trust the wrong material. Before you add the new key to your offline package trust store, confirm its fingerprint through a channel you already trust, such as direct contact with Collabora or the customer portal if you hold a subscription. Record the change with the date, the fingerprint and the approver. Once the estate has moved to the new key, retire the old one and write the procedure down so the next key change follows the same path.

Is CODE suitable for a defence or classified deployment?

No. Collabora describes CODE (Collabora Online Development Edition) as suited to testing, home use or small teams, and not recommended for production, according to the CODE page. CODE is a rolling release published on average once a month, which does not fit a controlled patch process for an isolated network. For production, the supported route is a Collabora subscription. The Business plan on the pricing page costs 3 euros per user per month for up to 99 users and includes long term support, a service level agreement, signed security updates and customer portal access. Enterprise pricing for 100 or more users is quoted with volume discounts. Ask Collabora which plan applies to your user count and how signed updates are delivered to systems with no internet access.

How should packages be verified before they cross the boundary?

Verify each package's signature against the key you have confirmed, compare its checksum with the published value, and record both before the file enters the isolated network. Use the package manager's own signature tools for RPM and DEB files, keep the verification output with the transfer media, and reject any package that fails. Require a second person to approve each transfer record. This gate matters because NERC CIP-013-2 addresses verifying the integrity and authenticity of vendor software and patches as part of supply chain procurement, and it is a common reference point for energy operators. Other programs ask for comparable evidence, so confirm with your assessor which records they expect and keep the signed record with the artifact it describes.

How often should an offline Collabora Online estate be scanned for vulnerabilities?

Scan at least monthly where the FBI CJIS Security Policy applies. According to the California DOJ bulletin on version 6.1, which took effect on 26 June 2026, vulnerability scanning must occur at least monthly for systems handling criminal justice information. Other frameworks may set different intervals, so confirm your requirement with your assessor before you set the schedule. An air-gapped estate needs a scanner that works from offline vulnerability data, and that data must be refreshed by carrying it across the boundary the same way you carry packages. Scan again after each approved point release, and store the results and remediation dates next to your transfer logs.

How do we keep the offline mirror in step with the chosen branch?

Choose one supported branch for the estate and mirror only its point releases, so the mirror, the test environment and production stay on the same line. Moving to a new major branch is a separate upgrade project with its own plan, testing and approval. The 26.04 branch was announced on July 23, 2026, and includes an optional AI assistant that is off by default, so it needs its own review of features, administrator choices and data flows before it enters the boundary. Promote each point release through staging before production, in a planned window. Record the version each environment runs, so the mirror and the deployed set cannot drift apart. The release notes list the current releases for each branch.

Compliance evidence the build should produce

Defence and classified buyers need evidence that maps the deployment to the controls their assessors will test. The four cards below cover the control baseline, cryptography and scanning, cloud storage scope and the NIS2 boundary, and each one names what the build should record. DeployOpen prepares this evidence, but independent assessors and the relevant authorities make any determination.

Map controls to SP 800-53

Map each part of the Collabora Online build to NIST SP 800-53 Rev. 5 controls and select the baseline your authority requires. SP 800-53B defines low, moderate and high baselines that select 149, 287 and 370 controls and enhancements respectively. Record which controls the WOPI host, the Collabora server, the network boundary and the operating system each address, and mark the rest as inherited from your own environment. Ask your assessor which baseline and OSCAL profile they will test against.

Prove cryptographic strength

CJIS Security Policy v6.1 requires FIPS 140-3 validated modules or FIPS 197 AES with at least 256-bit keys for criminal justice information in transit and at rest outside physically secure locations. For Collabora Online, the evidence should show TLS termination, the WOPI connection between the host and the server, and storage encryption for documents cached on the server, each tied to a validated module. Confirm the module certificate numbers with your cryptography team before the assessment.

Schedule vulnerability scanning

CJIS v6.1 requires vulnerability scanning at least monthly under the RA-5 control family. The build should record which scanner covers the Collabora host, the container images or packages in use, and the operating system beneath them, plus how findings reach a patch decision. Track Collabora security advisories as an input to that process, including package signing key changes, and keep evidence of each applied update.

Confirm cloud storage scope

Under 32 CFR 170.17(c)(5), a CMMC Level 2 contractor may store or process CUI in a cloud service only if that service is FedRAMP Authorized at the Moderate baseline or higher, or meets equivalent requirements. A self-hosted Collabora server in your own accounts is not a third-party cloud service, but any hosted storage, backup or managed Kubernetes platform beneath it may be. Document each cloud service in the data path and ask your assessor how each one is scoped.

Document the NIS2 exclusion

NIS2 does not apply to entities working in national security, public security, defense or law enforcement. Before building against NIS2 obligations, confirm with counsel whether your organization falls inside that exclusion or inside a regulated sector that is in scope. Record the determination, the basis for it and the date it was reviewed, so the file shows why NIS2 controls were or were not applied to the Collabora deployment.

What defence teams ask before deploying Collabora Online in isolated networks

What does an air-gapped Collabora Online deployment cost?

Cost follows the written scope, so DeployOpen quotes from the enclaves, transfer process and accreditation evidence you need. The software itself is licensed separately: the Collabora Online Business plan is listed at 3 euros per user per month for up to 99 users, according to the Collabora Online pricing page, and it includes long term support, a service level agreement, signed security updates and customer portal access. Enterprise is quoted for 100 or more users with volume discounts and adds integration support and customization services. Ask Collabora for the license quote, and ask DeployOpen for a fixed-scope quote covering the build, the bundle transfer process and the evidence pack. Licensing recurs monthly per user, while the implementation is usually one-time, with run costs for patching and operations.

What drives the scope and effort of an isolated Collabora deployment?

The main drivers are the number of enclaves, how many times software and updates cross the boundary, and how much accreditation evidence the authority expects. Each enclave needs its own tested installation, reverse proxy, TLS and WOPI host configuration. Scope also grows with:

The number of WOPI hosts that will call Collabora, such as Nextcloud instances
The transfer process for packages, container images and fonts
Integrity checks on every carried package, which connects to the supply chain control in NERC CIP-013-2 for energy sector readers and to your own vendor verification policy in other sectors
Testing of document fidelity against your templates

When you request a quote, ask for each of these items to be listed separately so you can see what changes if the boundary changes.

How long does it take to deploy Collabora Online in an air-gapped network?

Duration depends mainly on boundary complexity, approval cycles and how many enclaves are involved, so no reliable duration can be stated before the scope is agreed. A single enclave with one WOPI host is a different project from a phased rollout across several networks with separate accreditation. Ask for a timeline in the written scope that separates the design, the build, the transfer rehearsal, accreditation evidence and the phased user migration, and confirm which approval steps sit on your side of the schedule. Your security authority's review window is often the longest item, and it is usually outside the implementation team's control.

What must our team provide before the engagement starts?

Before work starts, the client should be ready to provide the information that fixes the design. Typical inputs include:

Network diagrams for each enclave and the approved transfer points
The classification and handling rules that apply to documents
Identity and access requirements, including how users in each enclave authenticate
Access to the approved internal package mirror, container registry and certificate authority
Named approvers for changes and for accreditation evidence

In the first design session, confirm which controls are inherited from your existing authorization boundary and which must be shown for Collabora itself.

Can our internal team deploy Collabora Online in an isolated network without a partner?

Yes, an internal team can deploy it, provided it has Linux administration, reverse proxy, TLS and container or package skills, and time for a transfer rehearsal and testing. The Collabora Online product page lists Linux packages, Docker and Kubernetes as deployment routes, and the Collabora Online Helm chart README sets manual replica counts and WOPISrc-aware routing, which your team must test itself. Teams that lack this capacity, or that must meet an accreditation deadline, often bring in a partner for the design and build. Whichever route you choose, agree who owns patching, the transfer process and the evidence pack from day one, because those recur after go-live.

Can we keep the AI assistant disabled in Collabora Online?

Yes. According to the COOL 26.04 release post on the Collabora forum, the optional AI assistant across Writer, Calc and Impress is off by default, and administrators choose the AI provider and whether it is hosted externally or on their own infrastructure. For an isolated network, the safest default is to leave it disabled, confirm that in the deployed configuration, and record the setting in your baseline. Enabling it later should go through change control, with a check that any model endpoint sits inside the enclave. Confirm the exact configuration keys with Collabora for the version you deploy, since the release post does not list them.

What evidence should we expect from a deployment partner for accreditation?

DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and independent assessors or the accrediting authority make those decisions. Ask for documented configuration baselines, the transfer and integrity-check procedure, test records for document editing and access control, and a list of the software versions and patch records in each enclave. Ask your assessor early which evidence format they accept, so the deliverables match what they will review.

Where to confirm Collabora Online's current support and release facts

Before a design is signed off, confirm which Collabora Online branch and point release the design will run, and whether that branch will still receive security fixes for the planned life of the system. Start with the Collabora Online pricing page, which describes what the Business and Enterprise plans include, such as long term support, a service level agreement and signed security updates. Then read the Collabora Online release notes to map the branch you intend to use against its current point releases. Treat the free CODE edition as a test and evaluation option only, since Collabora itself does not recommend it for production. Get written confirmation of the support end date for the chosen branch before you commit to it.

For the WOPI side, the Nextcloud administration manual on Nextcloud Office configuration is the reference for how the host and the editing server should be configured. Confirm that the Collabora server URL uses the same protocol as the Nextcloud installation, ideally HTTPS, and that WOPI requests are restricted to the Collabora server addresses in your segment. Record the group restrictions for who may use the editor and who may edit rather than only view. Check these settings against the actual network design, because a document host in one enclave and an editing server in another will need explicit allow rules.

Some items cannot be settled from public documentation. Ask Collabora in writing whether the specific build can be obtained, verified and updated from inside your boundary, how signing keys are rotated for offline package sources, and what advisory notices will reach your team when no internet route exists. Ask your accreditation authority or assessor which controls, cryptographic modules and cloud or hosted-service boundaries they will treat as in scope, including any AI assistant features that could send content to an external provider. Only proceed to design approval once both answers are documented and attached to the system security plan.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For Collabora Online in defence and classified environments, the work starts with a written scope that fixes the boundary, the controls and the evidence before any package crosses into the isolated network.

How we scope

Written scope agreed before work starts, covering the isolated enclave, user groups and document types in use.
Inventory of WOPI hosts, ingress paths, identity sources and the Collabora Online version and branch to deploy.
Confirmation with your security and accreditation authorities of which control baseline and evidence set apply.

How we build

Air-gapped installation from a verified offline package set, with each artifact checked for integrity and authenticity before transfer.
Routing configured so every request for one document reaches the same Collabora pod, with WOPI allow lists limited to your hosts.
Testing of editing, copy and paste, format fidelity and classification-related access rules in a staging enclave before production.

How we hand over

Runbooks for installation, patch intake through the boundary, backup, restore and sizing decisions, written for your operators.
Configuration baseline and evidence packs that your assessors or auditors can review, without DeployOpen issuing any attestation.
Knowledge transfer sessions with your platform and security teams, with access to the systems handed over to your administrators.

How we support

Support and maintenance available as a retainer, covering scheduled patch cycles and review of Collabora security advisories.
Upgrade planning across Collabora Online branches, including staged testing before each move into the enclave.
Ongoing verification after each change, documented so that your records stay current for the life of the deployment.