How the Relay VM Is Secured
The relay is a small Windows VM that runs inside your own Azure subscription and reads your Microsoft 365 configuration so Calibrant can evaluate it. Because it holds tenant-wide read access, its security model is deliberately conservative. This page explains each layer of that model.
It runs in your boundary, not ours
You deploy the relay from a template into your subscription and your resource group. You can inspect it, restrict it, monitor it, and delete it at any time — Calibrant has no administrative access to the VM. The compute never leaves your tenant, and neither do your Microsoft credentials.
Catalog-only execution — no remote code channel
The relay cannot be sent code. When a scan runs, the Calibrant portal sends the relay a command that names an operation — nothing more. The relay resolves that name against a script catalogue compiled into the installed relay build; if the name is not in the catalogue, the command is rejected. No script text travels over the wire in either direction, so a compromised portal session or API response cannot make the relay run arbitrary code.
Every execution is also logged with the SHA-256 hash reported by the installed relay for the script and catalogue it used. These records provide useful provenance and can be compared with a known-good relay release; they are not remote attestation of a compromised relay.
No inbound network access
The relay has no public IP and no reachable inbound port: the network security group denies all inbound traffic, and the relay service itself opens no listener. It polls the Calibrant API outbound over HTTPS, picks up pending commands, and posts results back. Nothing on the VM is reachable for an attacker to connect to.
No stored Microsoft credentials — Managed Identity
The relay authenticates to Microsoft Graph and Microsoft 365 services with an Azure user-assigned Managed Identity: no Microsoft passwords, client secrets, or certificates exist on the VM, and Calibrant never sees or stores tokens for your tenant — tokens are issued by Azure directly to the VM and stay inside your boundary. The only secret the relay itself holds is its rotatable Calibrant API key, which authenticates it to Calibrant and grants nothing in your tenant. (Azure also requires a local administrator password at VM deployment — you set it, you keep it, and nothing in the relay uses it.)
Least privilege, and you can audit it
The identity holds 18 tenant-wide Graph application roles. They are all read-only, and the only directory role it holds is Global Reader, which is also read-only. Power Platform Administrator and Fabric Administrator were dropped in August 2026 after measurement showed those APIs authorize through a registration and a security group rather than through any directory role. The Fabric route is read-only by construction; the Power Platform registration is not, and is documented as the one surface where the relay's access exceeds read-only — it is also optional. The grant script is published and readable, scans begin with a preflight that reports the Graph and service permissions the identity's tokens actually present, and we ship an audit script, check-relay-permissions.ps1, that lists the full grant — including directory roles and the Power Platform registration — and flags anything no longer needed. Nothing in the catalogue mutates your tenant — which is a statement about what Calibrant does, not about what the Power Platform registration would permit.
AccessReview.Read.All permits reading all access reviews, reviewers, decisions, and settings, although Calibrant returns only aggregate review-coverage counts. The Office installation and Backup grants similarly expose organization settings or protected-resource lists while their collectors return only an update channel or policy counts. That minimization constrains the Calibrant catalogue, not someone who can execute code on the VM. Treat the relay and Managed Identity as a privileged reader and review the exact permission list.Updates only you approve
The relay updates itself only to versions you approve in the portal. Every release is version-addressed and integrity-verified (SHA-256) before install, the changelog for each version is shown at approval time, and there is no automatic mode. The full flow is documented in Updating the Relay.
Authenticated relay traffic
Every request between the relay and the Calibrant API carries a per-relay API key over TLS, and results are bounded in size so a misbehaving script cannot flood the service. The key can be rotated from the portal. A relay holds exactly one valid key at a time, so rotation is a brief planned outage rather than a seamless cutover — the rotation procedure sets out the order, the verification, and the recovery path.
Durable result delivery
The relay encrypts a completed collection with Windows DPAPI before it tries to deliver the result. The local outbox survives a Windows restart, retries until Calibrant confirms receipt, keeps entries for up to 24 hours, and is capped at 256 MB. The server binds a result to its exact command and accepts it once, so a retry cannot create a second audit result.
Results too large for a normal web request use a signed, resumable upload to private temporary storage. Calibrant verifies the expected size and SHA-256 digest before processing the evidence, then deletes the temporary object after consumption; bounded cleanup removes abandoned uploads. If the VM is deleted while its only copy of an undelivered result is still in the outbox, that result is lost and the scan must be run again.
Clean removal
Offboarding is documented and complete: deleting the relay's Azure resources plus revoking the granted roles removes every foothold. See Removing the Relay for the step-by-step, including the settings Azure does not remove for you.