Customer Lockbox deep dive

Customer Lockbox is the Microsoft 365 feature that requires explicit customer approval before Microsoft engineers can access tenant content data during a support case. It exists to satisfy strict regulatory requirements — and to give customer admins direct, auditable control over the rare cases where Microsoft engineers need access.

What Microsoft engineers can and can't do without Lockbox

Without Customer Lockbox, Microsoft's standard operating model is:

• Service operations — fully automated. Engineers never see customer content during normal operation.
• Metadata access — engineers can see metadata (mailbox sizes, login counts, error rates) needed to diagnose service issues.
• Content access via just-in-time elevation — for cases that genuinely require it, Microsoft's internal Lockbox (different from Customer Lockbox) requires the engineer to request elevation with approvals.

What Customer Lockbox adds is a second approval gate controlled by the customer.

When Customer Lockbox triggers

It triggers only when a Microsoft engineer's troubleshooting genuinely requires access to customer content data — not metadata, not service logs, not telemetry. Examples:

• A support case for specific mailbox content that can only be diagnosed by reading messages.
• A SharePoint case requiring direct access to a document showing corruption.
• A Teams case requiring inspection of chat content.

In most support cases, Microsoft engineers diagnose issues from telemetry without needing content access — so Customer Lockbox rarely fires in normal operation.

The approval workflow

When Lockbox triggers:

1. The Microsoft engineer submits a Lockbox request with case ID, justification, and scope.
2. The customer's Customer Lockbox Access Approver (an admin role) receives a notification in the admin center and via email.
3. The approver sees: engineer name, what they need to access, justification, support case reference.
4. Approver chooses Approve, Deny, or lets it expire (effectively deny).
5. If approved, the engineer gets time-bound content access logged in the audit trail.

The customer's decision is binding — there's no override. The trade-off is that genuinely needed support may stall if Lockbox isn't responded to.

Audit trail

Every Lockbox request and response is logged in Purview audit logs:

• The request itself (engineer, case, justification, requested permissions).
• The approver's decision (approve / deny, comments, timestamp).
• Any subsequent access by the engineer.

This audit trail is the artefact regulators care about — it proves third-party access happened only with documented approval.

Operational considerations

• Designate multiple approvers so a single absent approver doesn't block urgent support.
• Communicate to the support team that Lockbox approval is required and may delay diagnosis.
• Train approvers to make informed decisions — understand what's being requested, when to approve, when to ask follow-up questions of the support engineer.
• Document the policy so approvers have a framework for their decisions.

Licensing

Customer Lockbox is included in Microsoft 365 E5, Microsoft 365 E5 Compliance, Office 365 E5, and Microsoft 365 Apps for Enterprise (in some plan combinations). Standalone licensing is also available.

For most organisations Customer Lockbox is a "we have it but rarely use it" feature — and that's a good outcome. Activity is the exception, not the norm.