WOPI Security Beyond Proof Keys: Implementing Zero Trust for Cloud Document Editing

WOPI Security Beyond Proof Keys: Implementing Zero Trust for Cloud Document Editing

Proof key validation is the entry point for WOPI security — the mechanism that verifies every incoming request from Office Online is genuinely from Microsoft and has not been tampered with in transit. It is a well-understood control, and McKenna has previously written about implementing it correctly. But proof keys are one layer in a security stack that, for enterprise deployments in regulated industries, must be significantly deeper.

Organisations handling regulated documents — financial records, legal contracts, clinical notes, government correspondence — cannot rely on request validation alone. They need a security architecture that applies zero trust principles end-to-end: never trust any component implicitly, always verify every access request, enforce least privilege at every layer, and microsegment the network so that a compromise in one component cannot propagate laterally.

This article sets out the full WOPI host security architecture for enterprise deployments. It covers TLS configuration, OAuth 2.0 token lifecycle management, network controls, rate limiting, audit logging, and data-at-rest encryption — and maps every control to zero trust principles and the compliance frameworks that regulated-sector clients are most likely to require.

The Zero Trust Framework Applied to WOPI

Zero trust is an architectural philosophy, not a product category. Its foundational principles, as articulated by NIST SP 800-207 and the UK’s National Cyber Security Centre, are:

• Never trust, always verify: No component — user, service, or device — is implicitly trusted because of its network location. Every access request must be authenticated and authorised.
• Least privilege: Subjects are granted only the permissions required to perform their current task, for only as long as needed.
• Assume breach: Design systems as though adversaries are already present on the network. Limit blast radius through microsegmentation and audit everything.
• Explicit verification: Every access decision must use all available data points — identity, location, device health, time of request, and behavioural context.

Applied to a WOPI host, these principles translate into concrete engineering requirements at each layer of the stack.

Layer 1: Transport Security — TLS 1.3 Enforcement

The foundation of WOPI security is encrypted transport. The WOPI specification requires HTTPS, but the specification does not mandate which TLS version or cipher suites are acceptable. For enterprise deployments, this must be configured explicitly.

Enforcing TLS 1.3

TLS 1.3 removes the cryptographic weaknesses present in TLS 1.2: export-grade cipher suites, RSA key exchange (which lacks forward secrecy), and the negotiation overhead that enabled downgrade attacks. For a WOPI endpoint handling sensitive documents, TLS 1.2 should be considered a legacy fallback rather than a baseline.

Configure your WOPI endpoint to require TLS 1.3 as the minimum version:

# Nginx configuration
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;

# TLS 1.3 cipher suites are non-negotiable (always the three below)
# TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256

<!-- IIS / Azure App Service — web.config -->
<system.webServer>
  <security>
    <access sslFlags="Ssl, SslNegotiateCert, SslRequireCert" />
  </security>
</system.webServer>

For Azure App Service, enforce TLS 1.3 via the portal (TLS/SSL settings → Minimum TLS Version) or via the Azure CLI:

az webapp update \
  --resource-group <rg> \
  --name <app-name> \
  --set "properties.minTlsVersion=1.3"

HSTS Configuration

HTTP Strict Transport Security prevents protocol downgrade attacks by instructing browsers and Office Online clients to refuse plain HTTP connections. Set a long max-age and include includeSubDomains and preload:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Submit your domain to the HSTS preload list (hstspreload.org) to ensure enforcement before the first HTTPS connection is ever made.

Certificate Management

Use certificates from a publicly trusted CA for external-facing WOPI endpoints. For internal WOPI hosts on a private network:

• Use a CA whose root is trusted by the Office Online service infrastructure.
• Set certificate lifetimes of 90 days or less and automate renewal via ACME (Let’s Encrypt or equivalent) or Azure Key Vault certificate policies.
• Monitor certificate expiry with alerting at 30 days and 7 days. A WOPI host whose certificate expires silently breaks document editing for all users.

Zero trust principle applied: explicit verification — every connection is verified at the transport layer, not assumed safe because it arrives on an internal network segment.

Layer 2: OAuth 2.0 Token Lifecycle Management

Our previous article covered migrating from IDCRL to modern OAuth 2.0 authentication. Here we focus on the token lifecycle controls that go beyond initial issuance — the management of tokens throughout their lifetime, including refresh, revocation, and anomaly detection.

Token Issuance Controls

When issuing access tokens for WOPI sessions, apply the following constraints:

• Short expiry: Access tokens should expire in 60 minutes or less. WOPI sessions are interactive and short-lived; a 60-minute window limits the usefulness of a stolen token.
• Audience binding: Include an aud claim that binds the token to your specific WOPI endpoint. A token issued for your WOPI host should be rejected by any other service.
• Document binding: For highly sensitive documents, include the document identifier in the token claims. This prevents a token obtained for one document from being replayed against a different document.

{
  "sub": "user-id-guid",
  "aud": "https://wopi.yourdomain.com",
  "iss": "https://login.microsoftonline.com/{tenant-id}/v2.0",
  "iat": 1738540800,
  "exp": 1738544400,
  "document_id": "doc-guid-here",
  "scope": "wopi.read wopi.write"
}

Token Refresh and Rotation

Refresh tokens must be single-use and rotated on every use. Microsoft Entra ID supports refresh token rotation natively; if you issue your own session tokens alongside Entra tokens, implement the same pattern:

1. On each token refresh request, invalidate the presented refresh token immediately.
2. Issue a new access token and a new refresh token.
3. If the old refresh token is presented again after invalidation, treat this as a potential token theft: revoke the entire token family and require re-authentication.

Store refresh tokens in server-side session storage only. Never expose them to the browser through cookies, localStorage, or URL parameters.

Token Revocation

A zero trust architecture requires the ability to revoke access at any time — not just at token expiry. Implement the following revocation triggers:

• User-initiated session termination: When a user closes the document or logs out, revoke the associated access and refresh tokens immediately.
• Administrative revocation: Provide a management interface for administrators to revoke all active tokens for a specific user or document.
• Anomaly-triggered revocation: Revoke tokens automatically when anomalous behaviour is detected (see the rate limiting section).
• Entra ID integration: Subscribe to Microsoft’s Continuous Access Evaluation (CAE) signals. If Entra ID detects a risk event (impossible travel, credential leak, account compromise), your WOPI host will receive a real-time signal and can revoke the session without waiting for token expiry.

Zero trust principle applied: never trust, always verify — token validity is continuously evaluated, not assumed to persist from the moment of issuance.

Layer 3: Network Controls — IP Allowlisting and Microsegmentation

Office Online IP Allowlisting

Office Online communicates with WOPI hosts from a defined set of Microsoft IP address ranges. For internet-facing WOPI endpoints, restricting inbound connections to these ranges eliminates an entire category of unauthenticated attack surface.

Microsoft publishes the Office Online IP ranges as part of the Microsoft 365 endpoint data, available via the Office 365 IP address and URL web service. Automate the retrieval and application of these ranges — they change periodically as Microsoft updates infrastructure, and manually maintained allowlists go stale.

# Retrieve current Office Online IP ranges via Microsoft's API
curl "https://endpoints.office.com/endpoints/worldwide?clientrequestid=$(uuidgen)" \
  | jq '[.[] | select(.serviceAreaDisplayName == "Microsoft 365 Common and Office Online") | .ips] | flatten | unique'

Apply the retrieved ranges at the network boundary (NSG, WAF, or firewall) rather than in application code. Network-layer enforcement cannot be bypassed by application vulnerabilities.

For CSPP Plus partners, additionally allowlist the WOPI validator and discovery service IP ranges published in the CSPP Plus documentation.

Private Network Isolation

For enterprise deployments where the WOPI host serves internal users only:

• Place the WOPI host on a private network segment with no direct internet ingress.
• Route Office Online’s WOPI traffic through a private endpoint or Azure Private Link, keeping traffic off the public internet entirely.
• Use a dedicated subnet for the WOPI host with Network Security Group (NSG) rules that permit inbound traffic only from the Office Online IP ranges on port 443, and deny all other inbound traffic by default.

Microsegmentation

The WOPI host should not have unrestricted network access to your file store, database, or other internal services. Apply microsegmentation:

• The WOPI application tier has network access to the file store only on the specific port and protocol required (e.g., port 445 for SMB, port 443 for Azure Blob Storage REST API).
• The WOPI application tier has network access to the token cache (Redis) only on port 6380 with TLS enabled.
• No outbound internet access from the WOPI host except to Microsoft identity endpoints (login.microsoftonline.com) and, if applicable, your own telemetry pipeline.
• A separate management subnet for administrative access, separated from the data plane by a jump host.

Zero trust principle applied: microsegmentation — compromise of the WOPI application cannot be leveraged to access adjacent systems.

Layer 4: Rate Limiting and Abuse Prevention

High-volume document operations can be used to exfiltrate data at scale, probe for access control weaknesses, or exhaust resources through denial-of-service. Rate limiting is a compensating control that makes bulk abuse impractical.

Per-User Rate Limits

Apply rate limits per authenticated user identity, not per IP address — IP-based rate limiting is trivially bypassed by distributed clients and fails for users behind shared egress IPs:

Operation	Limit	Window
CheckFileInfo	120 requests	per minute
GetFile	60 requests	per minute
PutFile	30 requests	per minute
Lock / Unlock	60 requests	per minute
All WOPI operations (combined)	300 requests	per minute

These figures are illustrative baselines. Calibrate against your observed traffic patterns — a coauthoring session with many active users will generate more Lock refresh requests than a simple view session.

Per-Document Rate Limits

In addition to per-user limits, apply rate limits per document to prevent a legitimate user from performing an unusual number of operations on a single document (a potential indicator of automated exfiltration):

GetFile on document X by user Y: maximum 20 requests per hour
PutFile on document X by user Y: maximum 60 requests per hour

Anomaly Detection and Automatic Suspension

Implement automated responses to anomalous patterns:

• Impossible geography: A user authenticates from London, then from Singapore 15 minutes later. Suspend the session and require re-authentication with additional MFA.
• GetFile at unusual hours: A user who normally accesses documents during UK business hours downloads 50 documents at 03:00 GMT on a Sunday. Flag for security review and optionally suspend until manually reviewed.
• Mass download pattern: More than N GetFile operations within a rolling 1-hour window, where N is configurable per sensitivity tier. Automatically throttle to a lower rate limit and alert the security team.

Integrate with your SIEM (Splunk, Microsoft Sentinel, or equivalent) to correlate WOPI anomalies with signals from other systems.

Zero trust principle applied: assume breach — treat unusual behaviour as potentially malicious rather than assuming the authenticated session remains legitimate.

Layer 5: Comprehensive Audit Logging

For regulated environments, audit logging is not a debugging aid — it is a compliance requirement. Every document access event must be logged with sufficient detail to answer: who accessed this document, when, from where, and what did they do?

Required Log Fields

Every WOPI operation log entry must include:

{
  "timestamp": "2026-02-03T09:15:32.456Z",
  "operation": "GetFile",
  "result": "200",
  "document_id": "doc-guid-here",
  "document_name": "Q4-Financial-Report.xlsx",
  "user_id": "user-guid-here",
  "user_email": "user@client.com",
  "tenant_id": "tenant-guid-here",
  "session_id": "session-guid-here",
  "client_ip": "185.234.56.78",
  "office_online_session": "oos-session-id",
  "file_size_bytes": 524288,
  "duration_ms": 142,
  "user_agent": "Microsoft Office Online",
  "geo_location": {
    "country": "GB",
    "region": "England",
    "city": "London"
  }
}

The document_name field requires careful consideration: log it for operational utility, but ensure the logging pipeline itself is access-controlled — the audit log must not become a secondary route for unauthorised information disclosure.

Log Retention and Integrity

• Retain audit logs for a minimum of 12 months (ISO 27001 requirement) or longer as required by sector-specific regulation (7 years for FCA-regulated entities, for example).
• Write logs to a write-once, append-only store. In Azure, Log Analytics Workspace with immutable storage or Azure Immutable Blob Storage satisfies this requirement.
• Generate and store a cryptographic hash (SHA-256) of each log batch at the time of writing. This enables verification that logs have not been modified.
• Restrict access to audit logs to the security team only. Developers and operations staff should not have the ability to read or delete access logs for documents they do not own.

Log Alerting

Configure alerts on the following patterns:

• Any access to documents classified as “highly sensitive” outside of business hours.
• GetFile for a document by a user who has not previously accessed it and is not listed as an authorised collaborator.
• Failed authentication followed by a successful authentication within 5 minutes (potential credential stuffing with valid credentials found).
• Any PutFile that changes a document’s size by more than 80% (potential document replacement or corruption).

Zero trust principle applied: assume breach and verify explicitly — comprehensive logging enables forensic investigation of any security incident and demonstrates due diligence to auditors.

Layer 6: Data-at-Rest Encryption

The WOPI host’s file store contains the document content itself. If the storage layer is compromised, encryption at rest is the last line of defence.

Encryption Standards

Use AES-256 encryption for all documents at rest. In practice, for most deployment targets:

• Azure Blob Storage: Server-side encryption with AES-256 is enabled by default. For regulated environments, use customer-managed keys (CMK) via Azure Key Vault rather than Microsoft-managed keys. CMK gives you control over key rotation and the ability to revoke access to all data by revoking the key.
• Azure SQL / PostgreSQL: Transparent data encryption (TDE) with customer-managed keys provides equivalent protection for document metadata.
• On-premises NFS / SMB file stores: Use BitLocker (Windows) or LUKS (Linux) for volume-level encryption. Ensure encryption keys are stored separately from the encrypted volumes.

Key Management

Encryption is only as strong as key management:

• Store encryption keys in a dedicated key management service (Azure Key Vault, AWS KMS, or HashiCorp Vault) — never in application configuration or environment variables.
• Rotate encryption keys annually or immediately following a security incident.
• Implement key access logging: every decryption operation should generate an audit record in the KMS, separate from the WOPI application log.
• Use envelope encryption: data encryption keys (DEKs) encrypt individual documents; key encryption keys (KEKs) encrypt the DEKs. This allows key rotation without re-encrypting all stored documents.

Document Classification and Tiered Encryption

For implementations handling documents at multiple sensitivity levels, consider tiered encryption:

• Standard documents: Server-managed keys with HSM backing.
• Sensitive documents: Customer-managed keys in a dedicated Key Vault instance with access logging and restricted administrator access.
• Highly sensitive documents: Additional application-layer encryption using keys that are only decrypted into memory for the duration of a WOPI operation, with keys never written to disk.

Zero trust principle applied: least privilege and assume breach — even if an attacker gains access to the file store, encrypted data without the keys is useless.

Zero Trust Architecture Reference

The following describes the full security architecture for an enterprise WOPI deployment:

[Office Online (Microsoft)] ──TLS 1.3──► [WAF / DDoS Protection]
                                                    │
                                         IP Allowlist (O365 ranges)
                                         Rate Limiting (per-user, per-doc)
                                                    │
                                         [WOPI Application Tier]
                                         ├── Proof key validation
                                         ├── OAuth 2.0 token validation
                                         ├── Document authorisation check
                                         └── Audit log write
                                                    │
                          ┌─────────────────────────┼─────────────────────────┐
                          │                         │                         │
               [Token Cache]              [File Store]                [Audit Store]
               Redis TLS 6380             AES-256 CMK                Immutable log
               Private endpoint           Private endpoint            append-only

Every arrow in this diagram represents an authenticated, encrypted, least-privilege connection. No component trusts another based on network location alone.

Compliance Mapping

The following table maps WOPI security controls to the requirements of ISO 27001:2022, SOC 2 (Trust Services Criteria), and Cyber Essentials Plus — the three frameworks most commonly required by enterprise buyers and regulated-sector clients in the UK.

Security Control	ISO 27001:2022	SOC 2 TSC	Cyber Essentials Plus
TLS 1.3 enforcement	A.8.24 (Cryptography), A.5.14 (Information transfer)	CC6.7 (Transmission encryption)	Secure configuration
HSTS and certificate management	A.8.24, A.5.31	CC6.7	Secure configuration
OAuth 2.0 with short-lived tokens	A.5.15 (Access control), A.8.5 (Secure authentication)	CC6.1 (Logical access security)	User access control
Token revocation and CAE integration	A.5.16 (Identity management), A.5.18 (Access rights)	CC6.2, CC6.3	User access control
IP allowlisting for Office Online ranges	A.8.20 (Network security), A.8.22 (Segregation in networks)	CC6.6 (Boundary protection)	Boundary firewalls
Network microsegmentation	A.8.22	CC6.6, CC6.7	Network segmentation
Per-user and per-document rate limiting	A.8.6 (Capacity management), A.8.16 (Monitoring)	A1.2 (Availability controls)	Malware protection
Anomaly detection and session suspension	A.8.16 (Monitoring), A.5.25 (Incident response)	CC7.2 (Anomaly monitoring)	—
Comprehensive audit logging	A.8.15 (Logging), A.5.33 (Protection of records)	CC7.2, CC7.3	—
Log integrity and immutability	A.8.15, A.5.33	CC7.3, CC7.4	—
AES-256 encryption at rest	A.8.24 (Cryptography)	CC6.1, CC6.7	—
Customer-managed key management	A.8.24, A.5.10 (Acceptable use of assets)	CC6.1	—
Document classification and tiered encryption	A.5.12 (Classification), A.8.24	CC6.1	—

ISO 27001:2022

ISO 27001 Annex A controls most directly applicable to a WOPI deployment cluster in three areas:

• A.8 Technological controls: Cryptography (A.8.24), network security (A.8.20–8.22), logging and monitoring (A.8.15–8.16), and secure authentication (A.8.5) are all addressed by the controls above.
• A.5 Organisational controls: Access control (A.5.15–5.18) and incident management (A.5.25) map to token lifecycle management, IP allowlisting, and anomaly-triggered response.
• A.5.33: Protection of records applies directly to audit log immutability and retention requirements.

For organisations pursuing ISO 27001 certification, a WOPI security architecture that implements all of the above controls will satisfy the evidence requirements for an Statement of Applicability covering document management information assets.

SOC 2 (Trust Services Criteria)

The most relevant SOC 2 criteria for a WOPI host are in the Confidentiality and Availability categories:

• CC6 (Logical and physical access controls): Token-based authentication, IP allowlisting, and encryption at rest directly satisfy CC6.1, CC6.6, and CC6.7.
• CC7 (System operations): Audit logging, anomaly detection, and incident response processes satisfy CC7.2, CC7.3, and CC7.4.
• A1 (Availability): Rate limiting and capacity management controls support the availability trust service criteria.

For SaaS ISVs seeking SOC 2 Type II reports, the WOPI security controls contribute substantially to the evidence required for audit. Importantly, the audit log completeness requirements above — who accessed what, when, from where — directly map to the evidence SOC 2 auditors will request.

Cyber Essentials Plus

Cyber Essentials Plus is increasingly required for UK government contracts and public sector procurement. Its five technical controls are:

1. Boundary firewalls and internet gateways: IP allowlisting for Office Online ranges and WAF protection satisfy this control.
2. Secure configuration: TLS 1.3 enforcement, HSTS, and disabling unnecessary services satisfy this control.
3. User access control: OAuth 2.0 with MFA, token revocation, and least-privilege document authorisation satisfy this control.
4. Malware protection: Rate limiting and anomaly detection contribute indirectly; full malware protection requires additional controls outside the WOPI stack (endpoint protection, server AV scanning of uploaded documents).
5. Patch management: WOPI host operating system and runtime patching falls outside the protocol-level controls covered here but must be documented for the assessment.

Note that Cyber Essentials Plus does not directly assess encryption at rest or audit logging — these are requirements of ISO 27001 and SOC 2, not CE+. However, they are increasingly expected as baseline hygiene by enterprise procurement teams even when CE+ is the stated minimum requirement.

Sequencing the Implementation

For ISVs adding these controls to an existing WOPI deployment, sequence the implementation to prioritise the highest-impact controls first:

1. Week 1–2: TLS 1.3 enforcement and HSTS. Lowest implementation risk, immediate transport security improvement.
2. Week 3–4: OAuth 2.0 token lifecycle hardening — short expiry, revocation endpoints, CAE integration.
3. Week 5–6: IP allowlisting for Office Online ranges. Requires testing against your deployment environment to confirm the correct IP ranges are applied.
4. Week 7–8: Audit logging to an immutable store with the required field set.
5. Week 9–10: Rate limiting — start with conservative limits and tune based on observed traffic.
6. Week 11–12: Data-at-rest encryption hardening — customer-managed keys if not already implemented.
7. Ongoing: Anomaly detection rules, alerting, and SIEM integration.

For greenfield WOPI implementations, build all controls in from the start rather than retrofitting. The architectural decisions — particularly microsegmentation, centralised token cache, and immutable audit logging — are significantly more expensive to add to a running production system than to include in initial design.

Working with McKenna Consultants

Implementing a zero trust WOPI security architecture requires expertise across protocol mechanics, cloud infrastructure, identity management, and compliance frameworks. The controls described in this article are not independent checklists — they interact with each other and with the operational characteristics of your specific deployment.

McKenna Consultants has designed and delivered WOPI security architectures for enterprise clients across financial services, legal tech, and document management — environments where the regulatory consequences of a breach are not hypothetical. Our WOPI practice covers every layer described in this article, from TLS configuration and Entra ID token management through to compliance mapping for ISO 27001 and SOC 2 audits.

If you are evaluating WOPI security for a regulated-environment deployment, building a compliance evidence pack for an upcoming audit, or hardening an existing WOPI integration that has grown beyond its initial security design, we would welcome the opportunity to work with you. Contact McKenna Consultants to discuss your WOPI security requirements.