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).
Admin consent (OAuth) — the fastest path
A Microsoft Entra administrator grants Permafrost's multi-tenant application a standing set of read-only permissions. After approval, the first sync begins immediately. There is no app to register and no credential for you to manage.
The trade-off: the application holds those granted permissions continuously. They remain in effect until an administrator withdraws consent in Entra. For many teams the speed is worth it, and the path can be hardened — see below.
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.
Hardening the admin-consent path
If you choose admin consent for its speed, several customer-side controls tighten it. Permafrost is a read-only CIEM, so these all constrain access to the platform itself — they do not change what Permafrost reads.
- Scope a Conditional Access policy to the application. Target Permafrost's enterprise application (its service principal) in a Conditional Access policy and restrict sign-in to expected conditions — for example, the IP ranges or named locations Permafrost connects from. This bounds where the granted permissions can be exercised.
- Review granted consent periodically. In Microsoft Entra ID → Enterprise applications → Permafrost EPM → Permissions, review the permissions that have been granted. If a permission is no longer needed, revoke it. Standing grants deserve a standing review cadence.
- Keep to least-privilege read scopes. Permafrost requests only read scopes, added progressively as you enable each cloud surface. Grant only the surfaces you use. See Azure permissions explained for every scope and the feature it enables.
- Keep revocation within reach. Admin consent can be revoked at any time, and revocation cuts access immediately. Knowing the path is short — Enterprise applications → Permafrost EPM → Revoke admin consent — is itself a control.
