Open-Xchange security hardening guide

What Open-Xchange security hardening covers before go-live

If you are about to expose OX App Suite v8 to users, or you have inherited a running install, security hardening covers five areas: ingress and TLS, east-west traffic between services, access to the data store and cache, protection of stored mail and files, and a patch cadence that keeps the platform inside its support window. Each area maps to a concrete set of settings, so the work is a checklist to verify, not a single switch to flip. The difficulty is that the platform is not one application. OX App Suite v8 runs on Kubernetes, is delivered as Helm charts that reference container images, and depends on Istio for traffic management. Redis handles caching and session storage, MariaDB with the InnoDB engine holds primary data, and a distributed file system holds OX Drive files and PIM attachments. Each of these layers has its own authentication, encryption, network exposure and update mechanism. A control that is correct in the chart values can still be undermined by a default in the cache, the database listener or the storage export.

The ingress design is the first decision. The requirements call for Istio with v8, and ingress-nginx is documented only as a basic option where Istio cannot be used. Choosing ingress-nginx is therefore a deliberate exception that you should record, justify and review, because the mesh is where mutual TLS between workloads, authorization policy and most east-west controls are configured. Confirm with Open-Xchange which Istio release line your chart version supports, since the requirements tie supported Istio versions to the latest release and two prior ones, and an out-of-window mesh becomes a security problem as well as a support one. Patching is the control that most often decays after go-live. Open-Xchange supports a standard release for 12 weeks, ending with the availability of the third following release, while an LTS release is supported until the next LTS plus six months. The support window therefore sets your patch cadence for Kubernetes, Istio, Redis, MariaDB and the App Suite images together. Before go-live, agree who owns each upgrade, how fast a security fix must be applied, and how you will test a Helm chart upgrade in a non-production cluster first.

Plan the hardening work against the layers, not the product name. Ask your team or partner to produce a written inventory of every exposed port, service account, secret, Redis instance and database user, then confirm each one against the requirements and the operations guide. Ask Open-Xchange to confirm, for your chart version, which Redis and MariaDB configurations are supported and which are your responsibility when you use an unmanaged or custom setup. Storage protection needs its own decision: NFS suits small to mid-size deployments, while object storage such as S3, Ceph RadosGW or Scality RING is typical for larger ones, and encryption at rest, access control and backup scope depend on which you choose. Finally, treat hardening as evidence you can show later. Keep the configuration in version-controlled chart values, record each exception and its owner, and retain the results of ingress, TLS and network policy checks. DeployOpen can prepare that evidence and run security testing against the deployed platform, but independent auditors and certification bodies decide whether your controls meet a given framework. Confirm the scope of any assessment with them before go-live rather than assuming the hardening work settles it.

Which OX App Suite components hold the attack surface

Six components in an OX App Suite v8 deployment hold data, expose services or control how traffic moves between them. Each card names one of them and the checks to confirm against the Helm chart and operator documentation before you set a hardening baseline. Together they define the boundary that the rest of this page builds on.

Istio ingress and gateway

Istio is the ingress layer for OX App Suite v8 where it can be used, and it receives every browser and client session that reaches the platform from outside the cluster. The gateway configuration decides which hostnames and ports are exposed, which TLS versions and certificates are presented, and which routes reach the middleware. Confirm with the chart and Istio documentation which gateway resources the chart creates, how certificates are issued and rotated, and which Istio release line your cluster will run. If Istio cannot be used, the basic ingress-nginx option changes this control point.

Kubernetes namespace and network policy

The namespace and network policy layer determines which pods can reach the middleware, the Redis cache, the MariaDB database and the storage mounts. Kubernetes permits pod-to-pod traffic unless a network policy restricts it, and enforcement depends on the cluster's network plugin. Ask the chart maintainers which policies ship with the chart, which ports each workload opens and which workloads need access to the Kubernetes API. Confirm that cluster DNS and egress paths are limited to what each workload actually calls.

OX App Suite workloads

The App Suite workloads run the web frontend, the middleware and the supporting services behind mail, calendar, contacts, Drive and Documents. Each workload holds credentials for the database, cache and storage, so each should run with only the privileges its role needs. Review the container images the chart references, the service accounts assigned to each pod, the secrets mounted into them and the security context settings applied. Confirm which image versions and tags the chart pins and how you will verify them before each rollout.

Redis caching and session storage

Redis 7.4.x holds caching data and session storage for OX App Suite v8, and the littlered operator deploys it by default. Session data can identify signed-in users, so access to the Redis endpoint and its authentication settings matter as much as the data itself. Confirm with the littlered operator documentation how authentication, TLS and persistence are configured, which namespace Redis runs in and whether it is reachable from outside the App Suite workloads. If you use an unmanaged or custom Redis, you own these settings and their testing.

MariaDB with InnoDB

MariaDB with the InnoDB storage engine is the primary data store for OX App Suite v8. The supported lines are 10.6.x, 10.11.x, 11.4.x and 11.8.x, and Galera Cluster is supported for replicated deployments. Confirm which line the chart expects, how database credentials are created and rotated, which accounts the middleware uses and whether client connections must use TLS. Galera adds replication traffic between nodes, which needs its own network controls and access limits.

NFS or object storage for files

OX Drive files and PIM attachments are persistent data that must sit on a distributed file system. NFS suits small to mid-size deployments, and object storage such as AWS S3, Ceph RadosGW or Scality RING suits larger ones. This store holds the user content most likely to be sensitive. Confirm the export permissions or bucket policies, encryption at rest and in transit, the identities the workloads use to access it, and how deletion and backup behave. Check which encryption and retention features your chosen storage product provides in your environment.

Which ingress, TLS and access model to choose

This table compares the ingress, certificate, Redis, MariaDB, file storage and administrative access options that OX App Suite v8 deployments choose between. Read each row by checking the platform requirement first, then the fit and the ongoing work your team takes on. The main takeaway is that Istio and Galera add operating responsibility, so choose them only when your team can run them well.

Decision	When it fits	What it costs operationally
Ingress: Istio with mTLS between workloads	The default path, because OX App Suite v8 requires Istio. Fits when the cluster can run Istio and you need encrypted service-to-service traffic with identity-based policy.	Control plane and sidecar resource overhead, upgrades that stay within the Istio releases the requirements support, and troubleshooting of traffic policy. Confirm the supported Istio versions before you commit.
Ingress: basic ingress-nginx	Only where Istio cannot be used, as the requirements allow. Choose it when a platform policy blocks the service mesh, then document which encryption and access controls you add yourself.	A smaller platform footprint, but your team owns the compensating controls, such as network policies and workload encryption, and must show how they were verified.
Certificates: internal CA	Fits when all clients and services are internal and your policy keeps trust inside your own PKI. Public users and mobile clients will not trust the chain unless the root is distributed to them.	You run the CA, protect its keys, distribute the root certificate to clients, and maintain rotation and revocation procedures.
Certificates: public CA with cert-manager automation	Fits user-facing endpoints such as webmail and client autoconfiguration, where external clients must trust the chain without manual installs. Automated renewal reduces missed expiry dates.	Costs depend on the issuer and account you choose, so ask for them in writing. You still monitor issuance failures, validation method changes and renewal alerts.
Redis: default littlered operator or unmanaged custom instance	The default operator suits Redis 7.4.x for caching and session storage with a repeatable upgrade route. A custom or unmanaged instance fits when existing standards require a shared service, but it must still match the supported version.	The operator path adds CRD and operator upgrades to your change calendar. A custom instance moves authentication, TLS, persistence and failover ownership to your team.
MariaDB: single primary	Fits smaller deployments and teams that accept a simpler failover model. Supported series are 10.6.x, 10.11.x, 11.4.x and 11.8.x with InnoDB.	You plan and rehearse primary failover, verify backups by restoring them, and track patch levels within the supported series.
MariaDB: Galera Cluster	Fits when the platform needs multiple database nodes for higher availability. Galera Cluster is supported, so plan quorum and node placement from the start.	More nodes to patch, monitor and back up, plus quorum, flow control and split-brain recovery procedures that you must test.
File data: NFS or object storage	NFS fits small to mid-size deployments for OX Drive files and PIM attachments. Object storage, such as AWS S3, Ceph RadosGW or Scality RING, fits larger deployments.	NFS needs export permissions, a protected network path and share backups. Object storage needs bucket policies, encryption keys and lifecycle rules, plus storage licensing or hardware if on-premises.
Administrative access: through the cluster or a bastion	Cluster access fits small teams that already enforce strict RBAC and audit logging. A separate bastion fits when your assessor expects a hardened jump host with session logging.	Cluster access requires disciplined role design and audit review. A bastion adds a host you patch, harden, monitor and keep under the same access reviews.

How to harden OX App Suite in build order

This sequence hardens an OX App Suite v8 deployment in the order the controls depend on each other, starting with version prerequisites and moving through ingress, mutual TLS, network reachability, data stores, storage and secrets. Each step closes with a check that shows what the control blocks, so the platform team has evidence for its change record. Run the sequence in a staging cluster before production.

Confirm chart, Kubernetes and Istio versions
The platform team confirms that the Helm client is version 3.17.0 or newer, that the Kubernetes cluster sits within the N-1 or N-2 versions OX App Suite v8 supports, and that the Istio release is the latest supported release or one of its two prior versions. Check the matrix against the requirements page for the exact v8 release you plan to install, because supported versions change between releases. Record the versions in the change record and run a Helm dry run against the target namespace. Done when the dry run completes without version errors and the recorded versions match the matrix.
Establish Istio ingress with TLS termination
Create the Istio ingress gateway for the OX namespace and terminate TLS there, using a certificate from your internal or public certificate authority with a documented renewal process. Agree the certificate policy with the security team before go-live, covering issuer, key length, rotation, and the TLS versions and cipher suites the gateway offers. Redirect or reject plain HTTP. If Istio cannot be used, the basic ingress-nginx option is the alternative, and confirm with Open-Xchange which controls it supports. Check: run a TLS handshake test against the public hostname, confirm the presented chain and expiry date, and confirm that a plaintext request never reaches the web tier.
Enable strict mutual TLS between namespaces
Set Istio peer authentication to strict for the OX namespaces so that workloads accept only mutually authenticated traffic from the mesh. Confirm first that the chart version and Istio version allow strict mode across every namespace in use, including the Redis operator and any storage components. Where a component needs a permissive exception, document it, limit it to that workload and plan its removal. Apply the policy in staging before production. Check: inspect the proxy configuration for the STRICT mode on each namespace, and confirm that a test pod without a sidecar cannot open a connection to the web service.
Apply default-deny network policies, then allow flows
Apply a default-deny ingress and egress policy to the OX namespaces, then add explicit allow rules for each required flow: ingress gateway to web, web to middleware, and middleware to Redis, MariaDB and the storage endpoints. Scope each rule by pod label and port, and record the purpose of each rule beside it. Add DNS egress and any identity provider endpoint needed for single sign-on deliberately, one rule at a time. Check: run a traffic test matrix in which every allowed flow succeeds and every disallowed flow, such as web connecting directly to MariaDB, fails. Keep the matrix with the change record.
Restrict database users to required schemas and hosts
Create a separate MariaDB account for each OX component that needs database access, grant each account only the schemas it uses, and limit the allowed client host to the specific pods or the cluster address range that needs it. Remove default and anonymous accounts, and remove any manual administration account that no longer needs access. Confirm that the MariaDB version and topology you choose, whether single instance or Galera Cluster, support the same account model. Check: list the grants for each account and confirm that no global privileges remain, then attempt a login from an unlisted pod and confirm that the server refuses it.
Lock Redis to authenticated in-cluster access
Confirm how Redis is deployed, either through the default littlered operator or through a custom or unmanaged setup, because the available controls differ. Confirm the patch level of the supported Redis 7.4.x line against the requirements page. In either case, require authentication for every connection, keep the service reachable only from middleware pods through the network policies applied earlier, and disable or rename commands that the session and cache use does not need. Store the Redis credential in the cluster secret store, outside chart values. Check: an unauthenticated connection from inside the cluster should be refused, and a connection from a pod outside the middleware set should fail even with the credential.
Set storage permissions and encryption at rest
Files in OX Drive and PIM attachments live on a distributed file system, either NFS for smaller deployments or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones. Encryption at rest and access control are set in the storage platform itself, so the storage owner enables them and documents key management in writing. Restrict mount permissions so that only the middleware and file-handling pods can write, and confirm that other namespaces cannot read the mounted paths. Check: obtain the encryption status and key policy from the storage owner, write a test object from an allowed pod, and confirm that a pod outside the allowed set cannot mount or read it.
Protect secrets and disable diagnostic endpoints
Move every credential, certificate and key into the cluster secret store, grant read access per service account, and remove plaintext values from chart value files and pipeline variables. Review the admin and diagnostic interfaces that the release exposes, disable those production does not need, and limit the rest to an administrative network or to authenticated operators. Confirm the endpoint list and the disable method for your release in the operations documentation before you change anything. Check: search the rendered manifests and values files for plaintext secrets and confirm none remain, then request each admin or diagnostic path from an ordinary user pod and confirm the request is refused.

Protecting database, Redis and file storage access

OX App Suite keeps its state in MariaDB, Redis and a distributed file system, and each of these stores holds mail, sessions or user files. The cards below cover how to scope access to each store, how to rotate the credentials that open them, and how to protect the backups and snapshots that copy the same data.

MariaDB user and grant scoping

OX App Suite v8 uses MariaDB with InnoDB as its primary data store, on supported versions 10.6.x, 10.11.x, 11.4.x or 11.8.x. Create separate database accounts for each service or administrative task, grant each account only the schemas and privileges it needs, and avoid sharing a single superuser across the platform. Confirm with your DBA which accounts the chart expects and which ones should be restricted to migrations.

Redis authentication and reachability

OX App Suite v8 uses Redis 7.4.x for caching and session storage, deployed by default through the littlered operator or configured as an unmanaged or custom instance. Enable Redis authentication and confirm that only the middleware pods can reach the Redis service, using Kubernetes network policies. Session data stored here should never be reachable from tenant workloads or other namespaces.

NFS export restrictions

For small to mid-size deployments, OX Drive files and PIM attachments may sit on NFS. Restrict each export to the specific client addresses or node subnets that mount it, and use root squashing so that a compromised node cannot act as root on the share. Confirm with your storage team which mount options and export rules the chosen NFS server supports.

Object storage bucket policies and access keys

Larger deployments may store files in Ceph RadosGW, Scality RING or AWS S3. Give the platform its own access keys, scoped to the buckets it uses, and deny public read access on those buckets. Document which principal writes, which reads, and whether lifecycle or deletion rights are needed. Confirm the exact policy syntax and key features with each storage vendor, since they differ.

Rotation of database and storage credentials

Database passwords, Redis credentials and object storage keys all need a rotation plan that the operations team can carry out without downtime. Decide where secrets are stored, how Helm values reference them, and how a rotation is tested in a non-production environment first. Ask your Kubernetes and storage teams which secret management tooling is already approved for these credentials.

Protection of backups and snapshots

Backups and storage snapshots copy mail, calendars, contacts and Drive files, so they need the same access controls as the live data. Restrict who can restore, keep backup credentials separate from application credentials, and test restores on a regular schedule. Encryption options depend on your chosen database and storage platforms, so confirm at-rest and in-transit encryption with each vendor. Some OX modules may be licensed or packaged separately, so check the Operations Guide and your agreement to confirm which security features are included.

How hardening changes on Istio, ingress-nginx and air-gapped installs

Istio is the default model and the hardening baseline for OX App Suite v8, because the platform requires it. The mesh provides controls that the other two models must rebuild elsewhere: mutual TLS between workloads, identity-based authorization policies and one place to define how traffic enters the namespace. Most of your work is choosing modes, writing policy and proving that the policy is in effect.

Strict mTLS mode. Set peer authentication to strict for the OX namespace so plaintext connections between pods are refused. Confirm how Redis, MariaDB and storage clients join the mesh, and document any exclusion.
Authorization policies. Allow only the service accounts that need to reach mail, Redis and database endpoints, and deny other traffic by default.
Ingress gateway TLS. Terminate external TLS at the Istio gateway with certificates you manage, and set the minimum protocol version and cipher suites your policy requires.
Version alignment. Keep Istio within the supported window, which covers the latest release plus two prior releases, so mesh security fixes arrive on a known schedule.
Exclusions register. Record every workload that cannot run a sidecar and the compensating control for it.

Ask the deployment team to show live mTLS status and authorization policy output for each namespace, not only the configuration files.

How to test that hardening holds and fails safely

Verification has three parts, and each answers a different question. The first is whether the intended controls exist in the running cluster. Chart values describe intent, and the cluster shows what was actually applied. At the Istio ingress, confirm the accepted TLS versions, the certificate chain presented to clients and that plain HTTP is not served on the edge. Then list the policy objects in each namespace, including Istio authorization and peer authentication rules and Kubernetes network policies, and compare them with your reviewed design. Check that Redis 7.4.x and MariaDB accept only the identities and source workloads the middleware needs, and that the storage layer refuses mounts from workloads outside the file-storage role. Object names change between chart versions, so confirm them against the release you deployed.

The second part is negative testing from positions the design says should fail. Start with a pod in a namespace that has no labels and no policy exceptions, and attempt connections to the middleware, Redis, MariaDB and the file storage mount. Repeat the checks from a workload allowed to reach one service but not another, because permitted-but-unnecessary paths are where lateral movement tends to succeed. Then run the same checks from outside the cluster, against the public ingress hostname and any node or load balancer address that is reachable. Include unauthenticated Redis commands, MariaDB logins with valid credentials from the wrong source, and attempts to mount the storage export. For each test, record the expected result, the actual result and the log entry produced, so your team and any later assessor can trace the outcome.

The third part tests how the platform fails. Use a staging environment that mirrors production topology and run each failure on purpose. Let a certificate expire, or install one that does not match the hostname, and observe what the web client shows. Users should receive a clear error, not a silent loop, and sessions should stop working at their intended lifetime. Stop the Redis service and confirm that sessions are invalidated or re-established safely, without falling back to an unauthenticated state. Interrupt MariaDB connectivity and the storage mount separately, and check that mail submission is queued or rejected with a visible error, with no silent loss. Review logs during each test for session tokens, passwords or message content. Treat any fail-open result as a defect to fix before go-live.

Finally, plan an independent penetration test or security test of the deployed environment before production traffic arrives, and repeat it after material changes to ingress, identity or storage. Scope it against the running system, including the Istio gateway, the middleware API, the web client and the infrastructure around the cluster, and ask the tester to attempt the negative paths above from both inside and outside. Testing from a party that did not build the controls gives more useful findings. DeployOpen runs application, API and infrastructure security testing, so it can take part in this work, but ask any provider for the rules of engagement and the retest process in writing. Testing does not produce a compliance attestation. If a framework applies to your organization, the report comes from an independent auditor or certification body, and DeployOpen prepares the systems and evidence for that assessment.

What drives hardening effort and how to keep it down

This table lists the factors that expand or shrink an OX App Suite hardening scope, why each one adds work, and how to keep it contained. Read it before requesting a quote, because each row is a question your written scope should answer. The main takeaway is that environment count, integration count and storage design usually set the workload more than the base platform does.

Driver	Why it adds effort	How to reduce it
Number of environments	Development, test and production each need their own Helm value sets, and the same controls must be applied and evidenced in every one. Drift between value sets is a common source of rework.	Keep one base values layer with environment overrides limited to hostnames, sizes and secrets. Ask the scope to state which controls apply to every environment and which are production only.
SSO through OpenID Connect or SAML	Each identity connection adds redirect URIs, token validation, session lifetime and autologin rules that must be tested against the middleware login configuration.	Pick one protocol for the production identity provider and limit the number of connected providers. Confirm which login settings are fixed in the scope and which the client will own.
External SMTP relays and directory connections	Relay credentials, TLS settings, allowed senders and directory bind accounts each need secret handling, least-privilege access and network path rules.	Use a single documented relay per environment, store credentials in the cluster secret store, and scope directory accounts to read-only access. Ask for a list of every outbound and inbound path in the written scope.
Storage type and size	Drive files and PIM attachments sit on NFS for smaller deployments or on object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones. NFS exports, bucket policies and encryption at rest each need separate controls.	Choose the storage class early and document it in the architecture record. Ask for access controls and encryption settings to be listed per storage type so the scope does not depend on assumptions.
Galera Cluster in use	MariaDB Galera adds replication traffic between nodes, state transfer paths and additional ports that must be restricted and encrypted. Each node is a separate exposure point for the database layer.	Restrict replication ports to cluster members with network policies, enable TLS for replication where the version supports it, and test node loss before sign-off. Confirm whether a single primary or multi-primary setup is planned.
Custom middleware or UI plugins	Custom code can open new HTTP endpoints, read additional data or bypass standard input handling. Every new endpoint needs review, authentication checks and regression testing after each release.	Keep custom work to the smallest set of plugins needed, review each one against the platform's security model, and record which endpoints it adds. Ask the scope to include a per-plugin review and an upgrade test.
Compliance frameworks to evidence	Each framework asks for specific evidence, such as access logs, change records, backup restore tests and vulnerability management records. Controls mapped to several frameworks often need separate evidence packages.	Agree one control matrix that maps each platform control to every framework in scope. DeployOpen prepares systems and evidence for assessment, but independent auditors issue any report, so confirm the evidence format with your assessor before work starts.

Keeping hardening current within the support window

Patch cadence is a security control because a release outside its support window stops receiving fixes, and every hardening measure in this topic depends on the platform still receiving them. Under the Open-Xchange support commitment, a standard release is supported for 12 weeks, ending with the availability of the third following release. An LTS release is supported until the next LTS release plus six months. The current LTS is v8.47 (FCS 2026-03-18). v8.35 (FCS 2025-03-12), the first v8 LTS, is now discontinued, so any deployment still on it is running without vendor fixes. The newest release listed is v8.53, with first customer shipment on 2026-09-23. Confirm your current release and its end-of-support date before you plan the next change window.

Choose the release line deliberately rather than drifting onto whichever version was installed first. Standard releases suit a team that can test and roll out often and wants fixes quickly. The LTS line suits organizations whose change control requires fewer, longer-lived upgrades. Either way, write down the end-of-support date for your version and put the next required upgrade on the calendar before go-live. Test every Helm chart upgrade in a staging environment built from the same chart version, the same values files and the same Redis and MariaDB versions as production. Confirm that the Helm client meets the 3.17.0 minimum and review the rendered diff of the chart values before anything reaches production.

After each upgrade, re-run your network policy and TLS checks rather than assuming the previous configuration carried over. Chart upgrades can regenerate Kubernetes resources and Istio objects, so confirm that the ingress gateway still terminates TLS with the approved certificate and protocol settings. Verify that the network policies still restrict access to MariaDB, Redis and the storage back end to the pods that need them, and that no new pod has gained a route it should not have. Keep the results as dated evidence in your change record, because these checks are what an assessor will ask to see after an upgrade.

Cluster components move on their own schedules, so track their patches together with the application. OX App Suite v8 supports Kubernetes versions N-1 and N-2, and it requires Istio, supporting the latest Istio release plus two prior versions. A cluster upgrade can therefore take you outside the supported matrix even when the OX release is current, and an Istio upgrade can change ingress behavior your TLS checks depend on. Keep one record that lists the OX App Suite release, the Helm chart version, the Kubernetes and Istio versions, Redis 7.4.x and your MariaDB version. Before each change, confirm the current support matrix with Open-Xchange, because these tables change over time.

How much work is Open-Xchange security hardening, and what do we need to provide?

What does OX App Suite hardening cost, and what drives the price up?

No price applies until the written scope exists, and the quote follows from that scope. Cost rises with the number of control areas in scope: Istio ingress and TLS, network policies, MariaDB and Redis access, storage permissions for OX Drive files and PIM attachments, logging and the patch process.

Engagements are fixed-scope, so deliverables and timeline are agreed in writing before work starts. Costs fall into two groups. One-time work covers design, configuration, testing and documentation. Recurring work covers patch testing, release upgrades and periodic control reviews. Your team can run that recurring work, or it can sit under a retainer for ongoing support, upgrades and continuous testing.

When you ask for a quote, request one line per control area, the environments covered (production and non-production), whether the Kubernetes cluster already exists, and who performs recurring patch testing. Separately licensed modules are set by the license agreement and sit outside the hardening scope.

How long does OX App Suite security hardening take to complete?

Duration is set by the written scope, and the main drivers are the state of the platform and the decisions still open. A cluster that already runs Kubernetes, Istio, Redis and MariaDB shortens the start. Open certificate authority choices, pending storage access approvals and the number of environments (production, staging and recovery) lengthen it.

Testing is the other driver. Each Helm chart upgrade needs a regression pass on the hardened configuration, so your release calendar matters. Standard releases are supported for 12 weeks, ending with the availability of the third following release. An LTS release is supported until the next LTS release plus six months. Plan the hardening around the release you will run in production.

Ask for milestones, the dependencies on your side, and the acceptance criteria for each milestone before you sign.

What must our team provide before OX App Suite hardening starts?

Your team provides access and decisions. DeployOpen performs the design and configuration work inside your infrastructure. The standard list is:

Cluster access: administrative access to the Kubernetes cluster and its namespaces, granted through your change process.
Istio and certificate decisions: the Istio version, the ingress design, and which certificate authority issues the TLS certificates.
Storage and database admin access: administrative access to MariaDB, Redis and the distributed storage that holds Drive files and attachments.
A named owner for patching: one person who approves patch windows and accepts the test results.

Without these inputs, the work stalls at the first access request. Confirm each item in the written scope before the start date is set.

Can our team harden OX App Suite using only the public documentation?

Possibly, if the team has the skills and the time, but the public documentation covers configuration while your risk decisions stay with you. The OX App Suite requirements and the Operations Guide are public, and the AGPL-3.0 code mirrors are on GitHub. The team also needs working knowledge of Kubernetes, Helm 3.17.0 or newer, Istio, MariaDB with InnoDB, Redis 7.4.x and distributed storage.

The documentation does not settle which controls match your threat model, which evidence an auditor will request, or how to run patches inside the support window. The Operations Guide also notes that some modules may carry custom packaging, limitations or separate fees under the license agreement, so check that before you assume a feature is included.

A practical test: map each control area to a named owner in your team. If an area has no owner with the time to carry it, a fixed-scope engagement or a retainer is the more direct route.

Does DeployOpen issue security certifications for OX App Suite?

No. DeployOpen does not issue certifications, attestations or audit reports. Independent auditors and certification bodies perform those assessments. DeployOpen prepares the systems, controls and evidence that the assessments examine.

For OX App Suite, the evidence usually includes the configuration as deployed (Helm values, Istio policies and network policies), access records for the cluster, database and storage, patch and upgrade records, backup and restore test results, and the named owner for each control. Ask your auditor early which criteria apply and what records they expect to sample, because that determines how the evidence should be collected.

In the written scope, name the assessment you are preparing for and the environment it covers, so the evidence set matches what the auditor will review.

Does OX App Suite hardening work without Istio?

Not on the standard v8 design. OX App Suite v8 requires Istio and supports the latest Istio release plus two prior versions. A basic ingress-nginx option exists for cases where Istio cannot be used, so hardening without Istio is possible only on that path.

The controls change with that choice. Istio places TLS policy, traffic rules and service identity in one mesh layer. With ingress-nginx, TLS termination and routing controls sit at the ingress, and controls between internal services will need a separate design. Confirm in the requirements and the Operations Guide which hardening features apply to the ingress-nginx path before you commit to it.

Decide this at design time. Changing the ingress layer after the controls are in place means retesting the whole external path.

How do we keep OX App Suite hardening controls after the first release?

Controls drift with every upgrade, so each one needs an owner and a schedule. Standard releases are supported for 12 weeks, ending with the availability of the third following release. An LTS release is supported until the next LTS release plus six months, which gives a longer window for a production line that changes less often.

Keep the controls current with four habits:

A control register that maps each control to its configuration, owner and test.
Hardening tests after each Helm chart upgrade, run before the rollout reaches production.
A patch process that names the approvers and records each window.
Periodic version review of Istio, Redis and MariaDB against the supported matrix.

If your team lacks the capacity for these habits, a retainer covers ongoing support, upgrades and continuous testing.

How DeployOpen scopes, hardens and hands over OX App Suite

DeployOpen hardens OX App Suite inside your own infrastructure, whether that is your cloud account, data center or air-gapped network. Each engagement starts with a written scope that names the ingress, data stores, storage and release process to be hardened, and ends with documented controls your team can operate.

How we scope

Inventory the OX App Suite v8 components in scope: Istio ingress, TLS, Redis, MariaDB and file storage.
Confirm the Kubernetes and Istio versions against the supported matrix before any change is planned.
Agree the written scope, deliverables and timeline up front, since most engagements are fixed-scope.

How we build

Apply TLS and ingress controls through Istio, or the basic ingress-nginx option where Istio cannot be used.
Restrict pod-to-pod traffic with network policies, and limit database and Redis access to required workloads only.
Test the hardened configuration against your security requirements, then record each control and its evidence.

How we hand over

Deliver runbooks covering hardened configuration, Helm values per environment and the patch procedure.
Document how the mail and file storage protection controls are set, monitored and restored from backup.
Walk your operations team through the controls so they can run and verify them without DeployOpen.

How we support

Plan patching against the support commitment so each standard or LTS release stays inside its support window.
Test Helm chart upgrades in a non-production environment before each rollout to production.
Offer ongoing support, upgrades and continuous testing as a retainer, if your team needs it after handover.

Open-Xchange security hardening