Recovery Desk — BitLocker & LAPS

What it does

A technician needs a BitLocker recovery key. Today that means someone has access to the Intune portal — which also grants them everything else Intune can do, and leaves no record of which key they read.

Recovery Desk moves the lookup into ServiceNow. A person with the right ServiceNow role finds the device, gives a reason, and reveals the key. The disclosure is recorded before the value reaches them.

What you are actually buying

Not the lookup. Intune already shows the key. What this adds is the answer to the question an auditor asks: who read which recovery secret, when, and why.

• The disclosure log is append-only. Two layers enforce it. ACLs grant create, write and delete to nobody, with admin override off - a delete attempted as a full instance administrator over REST returns 403 ACL Exception Delete Failed due to security constraints. Business rules then abort update and delete for server-side scripts, which ACLs do not cover. Both are exercised by the shipped test suite.

The honest limit: a platform administrator with script access can call setWorkflow(false) and write to any table on their own instance. No application can prevent that, and one claiming to would be misleading you. What this does is make tampering deliberate rather than casual - and the table carries platform auditing, so a change that does get through leaves its own before-and-after record. • The record is written before the secret is handed over, so an attempt that then failed — a refusal, a device with no escrowed key — is on the record too. Those are the events an investigation cares about. • The secrets themselves are never stored. Keeping them would recreate, inside ServiceNow, exactly the uncontrolled copy this removes.

Looking is not revealing

Finding a device and seeing that it has three escrowed keys discloses nothing, and needs only the user role. Reading a key needs reveal. That split is what lets first-line confirm they have the right machine without holding the privilege to open it.

A third role, auditor, reads the log without being able to disclose anything — because the people who review disclosures are usually not the people making them.

It cannot write to your tenant

The Graph transport exposes one method, and that method issues GET. The HTTP verb is not a parameter anywhere in the code, so there is no write path for a future change to reach for. This application cannot create, modify, delete or rotate anything in Azure, and that is a property of its construction rather than a promise about its behavior.

Policy you set, not policy we chose

Compliance regimes differ, so the friction is yours to configure:

Reason required - on - No reveal without a written reason Ticket required - off - No reveal without a ticket reference Ticket must exist - off - The reference must match a real task, and is linked to it Repeat viewing - allowed - A secret already revealed can be read again, each viewing recorded Reveals per person per hour - 25 - A ceiling on how fast one account can drain the estate

There is deliberately no setting that turns recording off. It is what the product is for, and a switch to disable it would be the first thing an attacker looked for.

What it does not do

• It does not rotate keys or passwords. It reads what Azure already holds. • It does not create, modify or delete anything in your tenant. • It does not support on-premises Active Directory LAPS — Windows LAPS backed up to Entra only. • It does not replace Intune. It replaces handing out Intune access.