Product · Security & compliance controls
Controls for the people
who run the platform.
Authentication policy, mail security, tenant isolation, retention, audit trails and customer-controlled updates — the security and governance settings planned for Office Unbound, and what each is meant to do.
Project status These controls are planned across the core-services, MSP and enterprise, and hardening phases. Security architecture is part of the current phase; nothing on this page is available yet.
What this page covers
The product controls. The project’s approach to transparency and verification has its own page.
Security in a productivity platform is partly about how the software is built and partly about what administrators can do with it. This page is about the second: the settings, policies and records an organization or its MSP uses to decide who can sign in, how mail is filtered, how customers are kept apart, how long data is kept, what is logged, and when updates are applied.
How Office Unbound intends to make its own security checkable — public source, software bills of materials, build provenance, vulnerability advisories and the testing behind releases — is covered on Security you can inspect.
Running a platform yourself, or through a provider, means these controls are in your hands rather than a vendor’s. That is the point, and it is also a responsibility: defaults matter, and the platform is being designed so that the secure choice is the default one.
Intended controls at a glance
Each line shows its current status; none is available yet.
- Available Available and verified in a release
- In development Being built now
- Planned In the roadmap, not yet started
- Under evaluation Being assessed; not yet selected
| Capability | What it means | Status |
|---|---|---|
| Authentication policy | Password rules, MFA requirements, session lifetime and sign-in restrictions by group. | Planned |
| Role-based administration | Administrative roles with least-privilege scopes, including per-customer roles for MSPs. | Planned |
| Mail authentication | SPF, DKIM and DMARC published for outbound mail and checked on inbound mail. | Planned |
| Spam and malware filtering | Reputation, content scoring and attachment scanning on inbound mail. | Planned |
| Quarantine and review | Suspicious mail held for administrator review and release. | Planned |
| MailThreatZero integration | Optional additional phishing and threat filtering. | Under evaluation |
| Tenant isolation | Authorization, data and administrative boundaries between customer organizations. | Planned |
| Retention policies | How long mail, files and chat are kept, by organization or group. | Planned |
| Audit trails | Sign-ins, administrative changes and data access recorded centrally. | Planned |
| Data access controls | Who can reach which data, including administrators, with access logged. | Planned |
| Data export | Export of an organization’s data in documented formats. | Planned |
| Administrative reporting | Reports on accounts, MFA enrollment, sharing and policy status. | Planned |
| Legal hold and discovery | Preserving and searching data for legal matters, where implemented. | Planned |
| Customer-controlled updates | Operators choose when updates apply, with staging and rollback planning. | Planned |
| Security architecture | Threat model, service isolation and secret handling for the platform. | In development |
Authentication policy
Set once in the identity service and applied to every workload.
- MFA requirement
- Required for everyone, for administrators only, or for particular groups, with authenticator apps and security keys or passkeys as methods.
- Password rules
- Length and breached-password checks rather than forced rotation for its own sake.
- Sessions
- Maximum session length, idle timeouts, and the ability to revoke a user’s sessions across every service at once.
- Sign-in restrictions
- Lockout after repeated failures, and restrictions on where administrative sign-in is allowed from.
- Administrator separation
- Administrative roles scoped to what each person needs, with stronger requirements for privileged accounts.
- Security logging
- Successful and failed sign-ins, MFA changes and role assignments written to the audit log.
Mail security
Email is still the most common way attacks reach an organization. The mail service is being designed with layered checks on inbound mail and correct authentication of outbound mail.
Inbound mail, in order
Connection checks
TLS for the connection where the sender supports it, and reputation checks on the sending server.
Sender authentication
SPF, DKIM and DMARC evaluated, so mail claiming to be from a domain can be checked against that domain’s published policy.
Spam scoring
Content, header and statistical analysis, with candidates such as Rspamd.
Malware scanning
Attachments scanned, with candidates such as ClamAV.
Optional additional filtering
MailThreatZero as an additional layer for phishing and threat detection, where an organization chooses it.
Deliver, flag or quarantine
Clean mail is delivered, borderline mail marked as spam, and suspicious mail held in quarantine.
Outbound and domain setup
When a domain is added, the platform is intended to generate DKIM keys and give the exact SPF, DKIM and DMARC records to publish, then check that they are in place. Getting these right protects the organization’s domain from being spoofed and is a precondition for reliable delivery.
Quarantine review
Administrators review quarantined messages, release false positives and see why each message was held. Whether end users can review their own quarantine is intended to be a policy choice.
An optional integration for organizations that want filtering beyond the built-in layers. It would be a separate service with its own terms and costs. Under evaluation
Tenant isolation
When an MSP hosts many customers on shared infrastructure, the most important property of the platform is that one customer can never see another’s data. Isolation is being designed in several layers, so that no single mistake breaks it.
Authorization
Every request is checked against the tenant it belongs to, not only the user’s role.
Administrative boundaries
A customer’s administrators manage only their own organization; MSP technicians see only the customers assigned to them.
Data separation
Mail, files and chat stored with tenant-scoped access policies, and resource quotas per customer.
Testing
Cross-tenant access tests as part of release testing, aimed specifically at the boundaries.
Where requirements are stricter, the intention is that an MSP can run a separate instance per customer instead of shared multi-tenant infrastructure, at the cost of more infrastructure to operate. See Office Unbound for MSPs.
Retention, audit and legal hold
The compliance-oriented features, stated as features rather than as compliance.
Retention policies are intended to define how long mail, files, versions and chat messages are kept and when they are deleted, per organization or per group. Retention cuts both ways: keeping data too long creates exposure, deleting it too early can break obligations. The platform provides the controls; the organization decides the periods.
Audit trails are intended to record sign-ins, administrative actions, permission changes, sharing and access to data — including access by administrators — in a central log that can be searched, exported and kept for a defined period, and forwarded to an organization’s own log management.
Data access controls and exports are intended to let an organization see who can reach what, and to take its data out in documented formats when it needs to.
Legal hold and discovery — preserving data for a legal matter regardless of retention policy, and searching across it — are planned where they can be implemented across the underlying components. Each component stores data differently, so this is described as a goal, workload by workload, rather than a single switch.
Customer-controlled updates
With a cloud subscription, the vendor applies updates when it chooses. Office Unbound is designed so the operator — the organization or its MSP — decides when updates are applied, after testing them if it wishes.
- Notifications of new releases and security advisories
- Maintenance windows chosen by the operator
- Staging and testing before production
- Explicit approval of updates
- Rollback planning for each update
- An emergency path for critical security patches
- MSP-defined update policies across customers
Choosing when to update also means owning the consequences of waiting. A critical vulnerability with a published fix is exactly what attackers look for in systems that have not applied it. Office Unbound intends to make the severity of each update clear and to keep emergency patching quick, but deferring a critical patch remains the operator’s risk.
Rollback planning is not the same as a guaranteed undo. Some updates change stored data and cannot simply be reversed; release notes are intended to say when that is the case.
What we are not claiming
Office Unbound holds no security certifications and has had no completed independent security audit. It makes no claim of HIPAA, SOC 2, ISO 27001 or any other regulatory or certification status. The controls on this page are intended to help organizations meet their own obligations; whether a given deployment meets a given requirement depends on how it is configured and operated, and on the organization’s own processes.
Microsoft 365 and Google Workspace offer extensive compliance tooling and certifications of their own. Organizations that depend on those should weigh that carefully; see the Microsoft 365 comparison.
Assessing Office Unbound for security?
Tell us which controls and obligations matter in your environment. It shapes what is designed, tested and documented first.