Customer Lockbox

Customer Lockbox is a Microsoft 365 feature that requires explicit customer approval before Microsoft engineers can access tenant content data during a support case. Without Customer Lockbox, Microsoft's just-in-time access controls (Lockbox itself, in a different sense) protect content data internally but don't surface the request to the customer. With Customer Lockbox enabled, the customer admin receives a request in the Microsoft 365 admin center showing the engineer's name, the access needed, and a justification — and must approve or deny before any content access occurs. Available with Microsoft 365 E5 and as a standalone add-on. Important for regulated industries where third-party access must be audited and approved.

What it actually adds on top of Microsoft's normal support model

Microsoft's default support operating model already runs almost entirely on metadata — mailbox sizes, login counts, error rates — without any engineer touching actual content data, and the rare cases where content access is genuinely required already go through Microsoft's own internal just-in-time elevation and approval process. Customer Lockbox adds a second approval gate on top of that, one the customer controls: for the narrow set of support cases that genuinely need content access (reading specific message content to diagnose a mailbox issue, opening a document to diagnose corruption, inspecting chat content for a Teams case), the customer's designated approver sees the request and must explicitly approve it before access happens. Most support cases never trigger Lockbox at all, because most diagnosis is possible from telemetry alone.

Worked example

A tenant with Customer Lockbox enabled opens a support case for a SharePoint document that appears corrupted after a sync conflict. Standard telemetry can't fully explain the corruption, so the assigned Microsoft engineer submits a Lockbox request naming the case ID, the specific document, and the justification. The organisation's Customer Lockbox Access Approver — a named admin role, not just any Global Administrator — receives a notification in the Microsoft 365 admin center and by email, showing the engineer's name, exactly what they're requesting to access, and why. The approver reviews it against the open support case and approves it; only then can the engineer open the document. If the approver denies it, or the request expires unanswered, no content access happens and the case proceeds without it — the engineer works with whatever telemetry is available instead.

Common pitfalls

The most common misunderstanding is assuming Customer Lockbox governs all Microsoft access to a tenant — it doesn't; it only gates the narrow content-access path, and the vast majority of support interactions never touch it at all, which leads some organisations to conclude (incorrectly) that Lockbox "isn't working" because they never see a request. The second is not designating a responsive Customer Lockbox Access Approver, or designating only one person — Lockbox requests have a limited window to be approved before they expire, and a single approver on leave with no backup turns every genuinely-needed support escalation into a stalled case. The third is treating Lockbox as a substitute for the organisation's own access controls over its own staff and delegated partners — Lockbox specifically governs Microsoft engineer access; GDAP, Conditional Access, and PIM are the separate controls that govern everyone else who touches the tenant.