When teams plan an OX Guard implementation
OX Guard is the App Suite module for PGP-based encryption of email and Drive files, and rollout is mainly a set of key, recipient and licensing decisions. Teams usually reach this point when an organization already running OX App Suite must send encrypted mail or protect Drive files, often because the data is regulated or confidential. Banks, healthcare providers, public bodies and other organizations that handle sensitive records tend to start here, because the question is no longer whether encryption is needed but how it will be run.
Several teams usually share the work. The messaging or mail operations team owns the App Suite deployment and the Guard service. The security team sets the policy for which messages and files must be encrypted and how keys are protected. The identity team maps users, groups and any external recipient accounts. The data owners for each class of information decide who must be able to read what. Before any build starts, ask each team to name the person who signs off on key handling, recipient guidance and exceptions, because most delays come from decisions nobody assigned.
Guard does not stand alone. It runs on the App Suite deployment the client already operates or plans to build, so the plan has to cover the platform that App Suite depends on, including its identity login, storage for Drive files and attachments, and the backup and restore process. A change to any of these can affect how encrypted mail and files behave. If the organization is still choosing its App Suite storage or identity setup, settle those choices first, or at least record which ones Guard will depend on, so that the encryption design is not revisited later.
Licensing needs its own review. Open-Xchange's Operations Guide states that the right to use certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement, so Guard may be licensed and priced separately from core App Suite. Ask the licensing contact whether Guard is included in the current agreement, which features it covers, and which costs are one-time and which recur. The exact feature set and admin configuration should be confirmed against the Guard documentation for the release in use before the scope is written.
What OX Guard does inside OX App Suite
OX Guard is the encryption module that works alongside OX App Suite mail, Drive and Documents. The cards below separate what senders, administrators and external recipients each see and control, because each group carries different tasks and different risks. Where the documentation does not confirm a capability for your release, confirm it with Open-Xchange before you commit to a design.
Encrypting outgoing mail
Users compose mail in the App Suite interface and send it with PGP-based encryption applied, which is the module's documented role for mail. Check how a user chooses to encrypt a message, whether encryption can be enforced by policy, and what happens when a recipient has no key. Ask Open-Xchange to confirm each of these behaviors for your release, because the sender workflow determines training and support load.
Protecting Drive files
OX Guard extends PGP-based protection to files kept in OX Drive. Confirm which file types and sharing paths are covered, how an encrypted file appears to someone who has access but no key, and how previews, search and sync behave on encrypted content. The answers affect storage sizing, backup planning and what users expect when they open a shared file.
Guard for documents
The module's documented role includes enabling Guard for documents, which applies encryption to office files edited in OX Documents. Confirm with Open-Xchange whether this applies to your release, which document types it covers, and whether it depends on the Documents module. Open-Xchange's Operations Guide notes that some modules may be subject to separate fees set in the license agreement, so map that dependency before you promise document encryption to business owners.
Administrator key and policy controls
Administrators decide how Guard is enabled, which users can use it and how key material is stored and recovered. Document the key lifecycle before rollout: who creates keys, how keys are backed up, what happens when a user leaves, and how lost keys are handled. Ask Open-Xchange which settings the admin interface exposes for your release and which changes need configuration work or vendor support.
External recipient experience
External recipients who do not run OX App Suite need a way to read encrypted mail, and the method depends on the release. Confirm how recipients receive keys or access messages, which mail clients they can use, and what they must install or do on first contact. Test this with external mailboxes, including your most common partners, because support requests usually come from this group.
How OX Guard fits with App Suite mail, Drive and identity
OX Guard runs inside an OX App Suite stack that most clients already operate or are planning, so the first decision is whether the encryption rollout is treated as a change to that stack rather than an add-on. The v8 baseline matters here: App Suite v8 is delivered as Helm charts for a Kubernetes cluster, Helm 3.17.0 or newer is required, and the chart set expects either Istio or the basic ingress-nginx option for routing. Confirm with Open-Xchange which routing option your release and Guard configuration support, because the path a browser or mail client takes to reach Guard-enabled endpoints depends on it.
Redis and MariaDB carry most of the state that encryption touches. Redis 7.4.x handles caching and session storage, deployed by default through the littlered operator or supplied as a custom or unmanaged instance, and MariaDB with InnoDB is the primary data store with 10.6.x, 10.11.x, 11.4.x and 11.8.x listed as supported versions. Ask the vendor which Guard-related data is written to these stores, how long it persists, and whether any of it is included in backups, replication or Galera Cluster member copies. Encryption changes where sensitive content sits: encrypted message bodies and file contents will not be indexed or searched the way plaintext is, and backups that restore only the database and file tiers may not restore keys or decryption paths. Treat search expectations and backup restore tests as acceptance criteria, not assumptions.
Persistent files are the second place where content lands. Drive files and PIM attachments must sit on a distributed file system, NFS for small to mid-size deployments or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones. Encrypted Drive files change storage growth, deduplication and the restore procedure for the file tier, and any object storage lifecycle or versioning policy needs to be checked against the encrypted object format for your chosen release. Plan a restore drill that brings back database, file storage and key material together, and record which of these the vendor confirms as supported for your version.
Identity decides who can manage keys and who can decrypt. App Suite supports single sign-on through OpenID Connect, and Open-Xchange also documents SAML login configuration for the middleware. Whichever protocol you use, define which directory groups map to Guard administrators, which map to ordinary users, and what happens to a user's key material when the account is disabled, moved or deleted. Confirm with the vendor how Guard identities are linked to directory accounts, whether the link uses the same subject identifier as App Suite login, and how a re-keying or key recovery request is approved. A mapping error here can lock users out of their own mail or give administrators access to content they should not read, so test it with a pilot group before enabling it for all users.
Key handling and recipient decisions before rollout
This table compares the configuration decisions to settle for OX Guard before users or external recipients depend on it. Read each row as a choice with a risk attached, and confirm the supported option in your release before writing it into policy. Key custody and external recipient access drive most of the support and recovery work, so settle those two first.
| Decision | Options | Typical fit | Risk of a wrong choice |
|---|---|---|---|
| Private key generation and custody | Users hold their own keys; administrators generate keys; escrow where supported | User-held keys suit strict confidentiality. Administrator or escrow models suit recovery needs. Confirm which options your release offers. | Lost keys mean lost access to past messages and files. Escrow changes who can read mail, so it needs an approval step. |
| Public key distribution and verification | Keys published in the directory; keys exchanged out of band; manual fingerprint checks | Directory publication suits internal staff. Fingerprint checks suit high-sensitivity senders. Confirm the verification workflow in the product. | A substituted key can expose messages. Unverified keys make trust decisions hard to audit later. |
| External recipient access | Web-based reader or password-protected access; or the recipient's own PGP key | Web-based access suits occasional external partners. Own-key access suits recipients who already run PGP tooling. Confirm the supported path. | Recipients who cannot open messages will contact support or fall back to unencrypted mail. Test each recipient type before go-live. |
| Mail scope: default or on request | Encrypt all outbound mail; encrypt on user request; encrypt by rule for defined senders or recipients | Regulated mail usually needs a default or rule-based approach. On-request encryption suits low-volume internal teams. Confirm rule support. | Users who must remember to encrypt will miss messages. Broad defaults increase support load for external recipients. |
| Drive file scope | Encrypt all Drive files; encrypt selected folders; encrypt individual files on request | Folder-level scope suits defined teams with shared content. Per-file requests suit ad hoc sharing. Confirm whether folder scope is available. | Shared folders with mixed audiences can block collaborators. Files moved between scopes may lose their protection. |
| Guard for documents | Enable Guard for office documents and editing; or limit Guard to mail and Drive | Enable where documents hold regulated data and recipients can open them. Confirm whether document editing supports Guard. | Encrypted documents may not open in every editor or on every device. Confirm editing support before enabling. |
What external recipients must do to read encrypted mail
External recipients are the part of an OX Guard rollout that your own team cannot fully control, so decide how they will read encrypted mail before you announce encryption to users. Each outside correspondent needs a way to open a Guard message, and that path depends on the Guard release you deploy. Confirm with Open-Xchange documentation for that release which steps a recipient performs: whether they need their own PGP key, whether a recipient without one can use a password or web reader route, how the first message is verified, and which mail clients can open the result. Do not promise the flow to partners until your team has run it on that release.
Next, decide which external partners actually need encrypted exchange. A bank's payment operations team, an external auditor, outside counsel and a regulator's portal contact have different message volumes, tools and tolerance for setup work. Keep the list short for the first phase and record the business owner for each relationship. Support load follows from this list. Expect first-contact questions, lost passphrases, messages landing in spam folders, attachments that a recipient's gateway strips, and confusion when a recipient already uses a PGP key from another tool. Each of these reaches your help desk unless the process tells recipients where to go first.
Before a broad rollout, run a pilot with a small group of external correspondents who exchange mail with your staff today. Choose people who use different mail providers and devices, so the test covers common failure points across several setups. Give each participant the same scripted tasks: receive an encrypted message, open it, reply, and send a file stored in Drive. Ask them to note every step, every pause and every question. Your team should watch where people stall, which instructions they misread, and whether they can finish the task without help from an internal colleague. Repeat the pilot after each fix to confirm the change worked.
Write help desk documentation before the pilot ends, using what the pilot revealed. Include the recipient's first-contact steps with screenshots taken from the release in use, the exact error messages recipients report and what each usually means, and a short list of questions to ask before escalating. Set a rule that support staff never request or store a recipient's private key or passphrase in a ticket. Name who can reset access on the Guard side and who handles suspected misuse. Keep a per-partner note listing the agreed contact, the expected setup and the date the partner last completed the flow. Revisit these documents whenever you upgrade Guard, because recipient steps may change with the release.
OX Guard implementation sequence and what each step produces
The sequence moves OX Guard from release and licensing decisions to a monitored rollout across mail and Drive. Each step closes with a named deliverable, so key, recipient and support decisions are recorded before users depend on them.
Confirm the App Suite release line and support window
Start by confirming which App Suite release line your Guard deployment will run on. Use the Open-Xchange support commitment to check the support window: a standard release is supported for 12 weeks, ending with the availability of the third following release, and an LTS release is supported until the next LTS release plus six months. The current LTS is v8.47, and v8.35 is discontinued. The output is a release decision record that names the version, the support end date you confirmed in writing, and the trigger that will start your next upgrade.
Confirm Guard licensing and entitlements
Check the license agreement to confirm that your contract covers OX Guard for every mailbox group and Drive scope you plan to enable. The Operations Guide notes that rights to certain modules may depend on custom packaging, limitations or separate fees set in the license agreement, so ask for those terms in writing before planning begins. Your legal or procurement contact and your Open-Xchange account contact should both confirm the entitlement list. The output is an entitlement register that lists each module, its scope, and the named contact for licensing questions.
Design key handling and recovery rules
Security and data owners decide how PGP keys are created, stored, backed up and retired for internal users, and how external recipients receive and manage their access. Define who may hold recovery material, how lost credentials are handled, what happens at offboarding, and which records must be kept for audit. Confirm with Open-Xchange how Guard stores key material and whether recovery is possible under your design, because the answer changes the rules you can write. The output is a key handling and recovery decision record approved by the security owner and the data owners.
Build a pilot with internal and external recipients
Build a small pilot in a non-production environment with test mailboxes inside your organization and external test recipients on the mail services your users actually write to. Include encrypted mail with attachments, replies, forwards and Drive files shared with external people. Record each message path, including any mail gateway or antivirus scanning that touches the message. The output is a pilot report listing each test case, the recipient type, the result, each defect found, and a go or no-go recommendation for the next step.
Configure mail and Drive encryption scopes and admin controls
Using the decisions from the earlier steps, configure which users, groups and Drive areas can encrypt, what the default behavior is, and which administrator controls are available to support staff. Document each setting, who may change it, and how changes are logged and reviewed. Confirm each control against the Guard documentation for your App Suite version, and mark any control you could not confirm for follow-up with the vendor. The output is a configuration baseline and change record, tested against the pilot scope before anything moves to production.
Test interoperability with the mail clients in use
Inventory the mail clients your users rely on, including the web interface, desktop clients and mobile apps, and the versions in use. Test sending, receiving, decrypting, attachment handling, forwarding and replies in each combination that matters to your users, and include the external recipient experience for each service in the pilot. Where a client cannot complete a workflow, record the workaround and whether it is acceptable. The output is an interoperability matrix that lists each client, version, test result and documented workaround, signed off by the messaging owner.
Train help desk and users
Prepare help desk staff first, so they can explain what encrypted mail looks like to recipients, walk through external access steps, and handle key or access questions according to the rules from step three. Then prepare short user guidance for senders and recipients, based on the issues found during interoperability testing. Track who attended training and who needs a follow-up. The output is a help desk runbook section, a user guide, and a training attendance record that shows which support staff are ready to take tickets.
Roll out in waves with monitoring and a support runbook
Enable Guard for one user group at a time, starting with the group that the pilot covered best, and move to the next wave only when the previous one meets the rollback criteria you wrote in advance. Define what you will monitor, such as delivery failures, help desk tickets by category and external recipient issues, and assign an owner to each signal. Finish with an operations runbook that covers daily checks, escalation paths and how to disable Guard for a group if needed. The output is a wave plan, the monitoring definitions, and the operations runbook accepted by the service owner.
What drives OX Guard implementation effort and licensing cost
This table lists the factors that change how much work an OX Guard rollout takes and what licensing it requires, with the direction of each effect and how to keep it manageable. Read each row as a lever you can set during scoping. The main takeaway is that license terms and a narrow first pilot shape the quote more than any other single factor.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Mailboxes and users in scope | Each enabled mailbox adds key creation, onboarding, support contacts and testing. Effort rises with the count and with how many groups need different settings. | Start with a pilot group, such as one department or a set of high-volume senders, and widen the scope in later phases with written change requests. |
| Number of external recipient types | Each kind of outside recipient (customers, regulators, partners, consumers without a key) needs its own delivery path, instructions and testing. More types mean more configuration and more help desk questions. | Group external recipients into a small number of documented patterns and define the default path for each before the build starts. |
| Drive files and documents in scope | Encrypting Drive files and Documents content adds storage handling, sharing rules and user guidance on top of mail. Files already shared through links need a separate review. | Phase mail encryption first and bring Drive or Documents in as a separate, scoped workstream once mail works end to end. |
| Identity integration | Guard key handling depends on how users sign in and how their identities map to mailboxes. Directory attributes, group membership and single sign-on settings all need to match the App Suite setup. | Confirm the identity source and the mailbox-to-user mapping early, and document which accounts are in scope before any key material is created. |
| Existing App Suite deployment state | A current, supported and well-documented App Suite environment needs less discovery and fewer fixes than one with custom changes, old releases or unclear ownership. Gaps move into the scope. | Record the deployed release, the Kubernetes and storage setup and any local customizations during discovery so the gaps are visible in the written scope. |
| Guard licensing terms in the license agreement | The Operations Guide states that certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Licensing scope can decide whether the planned design is allowed at all. | Confirm in writing which Guard features, user counts and deployment models the agreement covers before scoping, and ask for any limits in the contract. |
| User training and help desk material | Users need to understand key handling, how external recipients receive mail and what to do when a message cannot be opened. Each new recipient type or feature adds material to write, translate and maintain. | Reuse one set of short guides for senders and recipients, limit the pilot to a small number of workflows and agree on the help desk escalation path before go-live. |
How OX Guard connects to the rest of the platform
OX Guard depends on the App Suite mail and file services, the sign-in layer, the Kubernetes routing layer, and the storage and backup paths beneath them. Plan these together, because a change in one area changes how encrypted mail and files behave in the others.
Mail, Drive and Documents attach points
OX Guard hooks into the mail and Drive experiences users already use, so its behavior must be verified in each. Mail encryption affects compose, read and attachment flows, and Drive encryption affects upload, sharing and download. OX Drive and OX Documents are adjacent implementations with their own planning, and enabling Guard for documents depends on how Documents and Drive are deployed. Confirm with Open-Xchange which Guard features apply to each module in your release line before you fix the scope.
OIDC and SAML sign-in
OX App Suite supports single sign-on through OpenID Connect, and the middleware documents SAML login configuration. Decide which protocol your identity provider uses, then confirm how Guard key unlock and external recipient flows interact with the login session. Ask Open-Xchange whether Guard key handling depends on the user's sign-in, and what happens when a session expires or an identity changes.
Routing layer and monitoring
App Suite v8 requires Istio, and ingress-nginx is a basic option where Istio cannot be used. Map which Guard endpoints pass through the mesh or ingress, and confirm any timeout, request size or header rules they need. Send Guard service health, error and latency signals to the same monitoring stack as the rest of App Suite, and confirm with Open-Xchange which Guard metrics and logs are exposed.
Storage backends for Drive
Drive files and PIM attachments must sit on a distributed file system: NFS for small to mid-size deployments, or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones. Test upload limits, quota accounting and preview behavior on your chosen backend with encrypted files. Confirm with Open-Xchange whether Guard encryption changes file sizes, object counts or deduplication, since these affect capacity planning.
Backup and restore for encrypted data
Backups must capture the MariaDB data store, the Drive and attachment file store, and any Guard key material, and they must restore to a consistent point. An encrypted file is readable only if its key material and database references survive together, so restore tests should open a sample of encrypted mail and Drive files after recovery. Confirm with Open-Xchange where Guard key material is stored and how it is backed up, rotated and recovered.
Mobile clients over Exchange ActiveSync
The Connector for Business Mobility syncs mail, calendars and contacts to phones over Exchange ActiveSync. Mobile clients may handle encrypted mail differently from webmail, so list the devices and apps you support and test reading, replying and attachment handling for Guard messages on each. Confirm with Open-Xchange whether Guard decryption works through this connector and which client versions were tested.
Questions buyers ask before bringing in an OX Guard partner
What does an OX Guard implementation cost, and what drives the price?
The cost depends mainly on scope, the number of users and external recipients, the number of integration points, and how much key policy work the project needs. A quote usually splits into one-time work (design, installation, configuration, testing, pilot support and knowledge transfer) and recurring items (support, upgrades and any licensing fees). Licensing is a separate line item that can change the total, so ask each vendor to state which costs are one-time and which recur. DeployOpen does not publish a price list. A quote follows from a written scope that names the environments, the user groups and the deliverables.
How long does an OX Guard rollout take, and what sets the timeline?
Duration depends on how much of the environment is ready when the project starts. The biggest drivers are the state of identity and mail infrastructure, the number of user groups in the pilot, how many key policies need sign-off, and whether Guard is added to an existing App Suite deployment or installed alongside a new one. Approval cycles, change windows and the time needed to test external recipient delivery also affect the schedule. Ask any partner for a phased plan with named milestones, the decisions each phase depends on, and the client tasks that sit on the critical path. No duration should be accepted without that breakdown.
What does an OX Guard rollout need from our identity and mail teams?
Identity and mail teams usually carry the most dependencies. The identity team needs to confirm how users sign in to App Suite, including any single sign-on setup, and which accounts will hold encryption keys. The mail team needs to confirm routing, the domains that will use Guard, how outbound mail is handled, and where logs are kept. Both teams should also name a pilot group and a contact who can approve changes during testing. Ask the partner to list these tasks in the scope so that each one has an owner and a date before the build begins.
Can our internal team deploy OX Guard without a partner?
An internal team can deploy OX Guard if it already runs OX App Suite, has Kubernetes and mail administration skills, and can give the project enough time. The harder parts are usually key policy design, external recipient experience, testing across clients, and documenting controls for an assessment. Confirm the platform prerequisites with Open-Xchange for your App Suite version, including whether Guard adds requirements beyond the base install. A partner is most useful when the internal team lacks capacity or wants a second review of the design. Either way, decide who will run Guard after go-live and how upgrades will be planned.
How does licensing affect the OX Guard decision?
Licensing can change both the cost and the architecture. Open-Xchange states in its Operations Guide that the right to use certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Confirm in writing whether Guard is included in your current agreement, whether it is priced per user or per deployment, and whether using it for external recipients or Drive files has any extra terms. Also confirm which App Suite release line your agreement covers, since support periods differ between standard and LTS releases. Make the licensing position part of the quote review so that no cost appears later.
How do we tell whether an OX Guard partner's quote is complete?
A complete quote lists each deliverable, the environments in scope, the user groups, the integrations, the testing approach and the client responsibilities. It should also state what is excluded, such as licensing, third-party components, hardware, storage upgrades or training. Check whether the quote covers key policy workshops, pilot support, documentation and a handover, and whether ongoing support is priced separately. Ask for the assumptions behind each duration and for a change process if scope shifts. If a line item is vague, ask the partner to restate it in the written scope before you compare offers.
Which key policy decisions must be made before OX Guard goes live?
Key policy decisions define who can encrypt, who can decrypt, how keys are created and recovered, and what happens when a user leaves. Leadership and compliance should decide which mail and Drive content must be encrypted, which recipients receive encrypted messages, and how external recipients authenticate. Security should decide how key material is stored and backed up, how access is logged, and who approves exceptions. These decisions shape configuration and user training, so settle them during design rather than during the pilot. Document each decision with an owner and a review date so that auditors and administrators can trace it later.
What should our engineers test before a pilot of external encrypted mail?
Engineers should test the full path a message takes, from sending to opening, for both internal and external recipients. Cover several mail clients and browsers, mobile access if it is in use, attachments, large files, forwarding, and messages sent to shared mailboxes. Confirm how Guard handles the Drive file and document scenarios in scope, and check the logs for each step. Test failure cases too, such as a recipient who loses access, a revoked key, a mail server outage and a misrouted message. Record the results and the fixes in a test report that the security and mail teams can review before the pilot starts.
How DeployOpen works on this
DeployOpen plans, implements, integrates, documents and supports OX Guard email and file encryption inside your own infrastructure, from a written scope agreed before work starts. The work covers key handling, the external recipient experience and enabling Guard for documents, with each step checked against your mail and file flows.
How we scope
- The written scope lists which mail flows, Drive files and user groups will use OX Guard encryption.
- Key handling decisions, such as where PGP keys are generated, stored and recovered, are recorded before any build begins.
- Engagements are fixed-scope, so deliverables and timelines for the Guard rollout are agreed in writing first.
How we build
- We configure OX Guard alongside your App Suite deployment, using the platform requirements you confirm for your environment.
- We design and test the external recipient experience, including how outside parties receive and open encrypted messages.
- We validate encryption for Drive files and document sharing, then record the results against the agreed scope.
How we hand over
- You receive configuration records, key handling procedures and user guidance written for your administrators and help desk.
- Runbooks cover enabling Guard for new users, key recovery steps and how encrypted content is handled during incidents.
- Knowledge transfer sessions walk your team through daily operation before the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing for Guard are available as a retainer after handover.
- Retainers can cover reviewing Guard behavior after each App Suite release you adopt, based on your support commitment.
- Ask any partner to confirm which OX Guard licensing terms apply to your deployment before scoping begins.
