Expiring secrets, rotated before they break anything.
ID Posture already flags a client secret before it expires. NHI Secret Rotation goes one step further: it rotates the secret directly in Microsoft Entra ID ahead of the deadline, then sends the right owner a short-lived, audited link to retrieve the new value from your own Key Vault. The old secret is left alone until it has already expired on its own, so nothing your applications depend on breaks mid-rotation.
From finding to fixed, without a manual handoff
Every other finding in ID Posture tells you something is wrong. This one also acts on it.
- You choose one Key Vault. Setup is two steps, done once: grant admin consent to a dedicated ID Posture identity built specifically for this feature, separate from the read-only identity used for scanning, and deploy one role assignment to the Key Vault you want new secret values to land in.
- ID Posture rotates the secret ahead of expiry. When a tracked application's client secret is approaching its deadline, ID Posture creates the replacement directly in Entra ID and writes the new value to your Key Vault. Your application's current secret is not touched or removed at this point.
- The right owner gets a link, not a value. ID Posture resolves who actually owns the affected application (its registered owners in Entra ID, falling back to a naming pattern or tag if needed) and emails that person a secure claim link. The email never contains the secret itself.
- The link grants access to exactly one secret. Clicking it grants that person read access to the one new secret value, nothing else in the vault, for 14 days. Your Key Vault stays the single source of truth. ID Posture never displays, emails, or stores the value anywhere.
- The old secret retires on its own schedule. ID Posture only removes the original secret after it has already passed its natural expiry, so a rotation never forces a cutover before your application is ready.
Detection was never the hard part
The gap this closes is a familiar one: ID Posture flags a secret expiring in 30 days, an alert lands in an inbox, and nothing happens until the day it actually expires and an integration quietly stops working. By the time anyone notices, it is an outage, not a warning.
NHI Secret Rotation is the first capability in ID Posture that does more than surface a finding. It closes the loop between "we told you" and "someone did something about it," without asking a human to remember, without a shared secret sitting in a ticket or a chat message, and without giving anyone standing access to your vault. Access is granted for one secret, to one resolved owner, for a fixed window, and it is gone again on its own.
What this covers today
NHI Secret Rotation is a genuinely new kind of capability for ID Posture, and it ships with an honest, stated scope rather than a claim of doing everything at once:
- Client secrets today, not certificates. Rotation currently covers application password credentials (client secrets). Certificate-based credentials are not included yet.
- One Key Vault at a time. The feature rotates into a single Key Vault you choose during setup, not every vault in your subscription.
- Your vault needs to use Azure RBAC. The target Key Vault must already use Azure's RBAC permission model. Vaults still on the legacy access-policy model are not supported yet.
- Off by default. Like every opt-in capability in ID Posture, this is disabled per tenant until an ID Posture contact turns it on for you.
ID Posture already tells you which secrets are expiring. NHI Secret Rotation is the difference between reading that finding and having it handled, rotated ahead of the deadline, handed to the right person through an audited, time-boxed link, with your own Key Vault as the only place the value ever lives.