Skip to content
Get started · Security

Connecting your tenant

Two ways to connect an Azure tenant to Permafrost — admin consent for speed, or your own app registration for tighter control. Both are read-only. Here is what each one means for the credential and who holds it.

Two paths, both read-only

Permafrost reads your Azure and Microsoft 365 entitlements to surface permission risk. It never writes during background sync. The choice is not about what Permafrost can see — that stays read-only either way — but about how it proves its identity to your tenant and what, if anything, it holds.

  • Admin consent (OAuth) — the fastest path. A Microsoft administrator grants Permafrost a standing set of read permissions in one click. Access persists until consent is withdrawn.
  • Your own app registration — stricter. You register Permafrost as an application in your own tenant. The credential lives in your directory. This path has two forms: federated (recommended; no stored credential) and client secret (a stored secret, held encrypted in HashiCorp Vault).

Your own app registration — stricter control

Instead of trusting Permafrost's multi-tenant application, you register Permafrost as an application inside your own tenant. Every Microsoft Graph call then attributes to a principal in your directory, which keeps sign-in and audit signals clean in Defender and Sentinel, and you control the credential's lifecycle directly. This path is available on the Professional plan.

There are two ways to authenticate the app you register:

  • Federated (workload identity federation) — recommended. No secret on either side. Permafrost stores nothing. It proves its identity per request with a short-lived token from its host, and your app registration validates that identity through a federated credential you create.
  • Client secret. You generate a secret in Azure and Permafrost stores it encrypted in HashiCorp Vault. A stored, longer-lived credential you rotate on your own schedule.

Why federated is the most secure option

With workload identity federation, Permafrost never holds a credential to your tenant. There is no secret to store, rotate, or leak — because there is no secret. Each request carries a short-lived, automatically issued token from Permafrost's host; your app registration trusts that host identity through a federated credential and validates the token before granting access. The trust is brokered per request, not held as a standing key.

You hold the kill switch. The federated credential lives on your app registration, and you can delete it at any time, unilaterally, without contacting Permafrost. The moment you do, the trust is gone and access stops. Compared with a stored secret — which exists somewhere and must be protected and rotated — federation removes the credential from the equation entirely.

Setup is brief: on your Permafrost EPM app registration, open Certificates & secrets → Federated credentials → Add, choose Other issuer, and paste the issuer, subject, and audience values shown in the connect wizard. A freshly created federated credential can take a few minutes to become matchable in Azure — if verification does not succeed on the first try, give it a moment and verify again.