Privileged identity response is the work that happens after a signal says an administrator, service principal, or OAuth grant may be compromised: decide what to change, change it, and prove the change held. Orbitra runs that work as one governed loop for Microsoft Entra ID and Azure. This page walks through the loop in the order it runs, from the read-only connection to the evidence receipt, and is specific about what is permanent, what can be undone, and what Orbitra can and cannot verify.
Step 1: connect read-only and build the privilege graph
Orbitra is agentless. It connects through Microsoft Graph and the Azure APIs; nothing is installed on endpoints. The connection starts read-only, with 8 read scopes for assessment. The 11 fine-grained write scopes used for response are consented separately, later, and only if you choose to move past observation. Wherever Microsoft offers a narrower scope, Orbitra requests the narrower one, and the destructive delete-user scope is deliberately excluded from consent.
From those reads Orbitra builds a privilege graph of the tenant, 11 node types and more than 30 relationship types spanning identities, groups, applications, roles, permissions, policies, devices, and Azure resources. Human and non-human identities (service principals, app registrations, OAuth grants, managed identities) sit in the same graph, because an attacker holding a client secret for an application with Directory.ReadWrite.All has the same reach as a rogue administrator.
The graph is what makes blast radius possible. Blast radius is a traversal across users, groups, apps, service principals, roles, and Azure RBAC that shows what an identity can reach before you act, and what remains reachable after. It is impact simulation, not exploit confirmation. Orbitra calculates identity impact before it acts, and the same traversal runs again after execution so the receipt can show the paths that were removed.
Step 2: detection is an input, not the product
Orbitra runs more than 70 deterministic detection rules against a 30-day behavioral baseline, with streaming detection on Entra sign-in and audit logs. Detections land in minutes, not seconds, and roughly 40 percent of the rules target applications, service principals, consent grants, and app credentials rather than people. There is no machine learning model scoring what is suspicious; each rule is a stated condition.
A detection never executes anything. It opens an incident, prioritizes it by the blast radius of the identity involved, and gives the reviewer the evidence. Whether the prompt is an Orbitra detection, a signal from a Microsoft tool, or a call from the help desk, the response starts the same way today: a person opens the identity in the console and reviews a plan. Detection without verified action is just noise; Orbitra treats detection as the front door to a response, not as the product. See identity threat detection and response for how the wider category is drawn.
Step 3: three postures, set per risk tier and per response pack
A response pack bundles the actions for one threat class, such as a compromised administrator or a suspicious OAuth application. Each pack carries a posture for each risk tier, and there are three:
- Recommend. Orbitra assembles the plan, explains each step, and stops. A person picks the actions and confirms each one.
- Approve. Orbitra assembles the plan and routes it to named approvers. Execution begins after approval and confirmation, and every step is still drawn from the allowlist.
- Autonomous. A tenant can pre-authorize specific actions for specific threat classes within blast-radius limits. Every autonomous action is pre-authorized by explicit policy, not decided by a model, and each policy-approved step is recorded as a timeline event.
Every customer tenant uses Recommend or Approve today, and Autonomous mode has never executed in a customer tenant. Read-only observation is the onboarding default, not a fourth posture. AI can summarize evidence and recommend from the allowlisted catalog; deterministic policy owns execution.
Step 4: the allowlisted catalog and its reversibility contract
Every response comes from an allowlisted catalog of more than two dozen governed response actions, and nothing outside the catalog can run. Each action carries a contract that states what it changes, which Microsoft scope it needs, whether it can be undone, and whether Orbitra can independently re-read the result afterwards. Orbitra tells you which steps are permanent before you approve them.
Some containment actions can be undone within the rollback window; others cannot. The split follows what Microsoft itself allows:
| Permanent (no undo path) | Undo within the window |
|---|---|
| Session revocation | Directory role removal |
| Password reset | Group membership removal |
| Credential removal (client secret or certificate) | Disable user |
| Azure role assignment removal | Disable application |
| PIM changes | OAuth grant revocation |
Undo is bound to the before-state Orbitra captured immediately before the action ran, and it is available for 24 hours by default. Restoring a directory role requires a human confirmation and never runs on its own. Restoring a revoked OAuth grant creates a new grant object with a new identifier rather than resurrecting the old one. Rollback is provided where the provider action is truly reversible; otherwise Orbitra provides a defined recovery path. The revoke sessions versus disable user guide explains why both columns usually appear in one plan.
Step 5: approvals from Slack, Teams, or email
When a plan needs approval, Orbitra sends it to the approvers where they already are: Slack, Microsoft Teams, or email. The approver sees the identity, its blast radius, the proposed steps, and which of them are permanent before deciding. Links expire, so a stale message cannot approve anything. Clicking a link never executes an action on its own; every catalog action requires an explicit confirmation, and high-impact steps confirm in the console rather than from chat. Who approved, from which channel, and when, all go on the receipt.
Step 6: execute, then independently re-read Microsoft
Execution is a series of Microsoft Graph and Azure Resource Manager writes, each using the narrowest scope the action needs. A success code from Microsoft means the request was accepted; it does not mean access has ended. Orbitra therefore distinguishes five states for every step: submitted, propagating, verified, residual access, and recovered. Containment is not complete until Orbitra re-reads Microsoft and the change held.
Orbitra independently re-reads Microsoft after supported response actions to verify the final state. The re-read is a separate read against the object that was changed, not the executor's own response, so a write that appeared to succeed but did not stick is caught. Where an action does not yet have an independent verifier, the receipt keeps the executor's read-back and records the step as receipt-only rather than verified. Orbitra never upgrades a step to verified on the strength of a success code alone.
Session revocation is the clearest example of why propagation is shown as estimated until it is observed. Microsoft's revokeSignInSessions invalidates the refresh tokens issued to applications for a user, and the session cookies in the browser, by resetting signInSessionsValidFromDateTime, and Microsoft notes there may be a small delay of a few minutes before tokens are revoked. Access tokens the user already holds stay valid until they expire, about an hour (60 to 90 minutes by default). Where both the client and the resource support Continuous Access Evaluation, an administrator revoking a user's refresh tokens is a critical event, and the resource rejects the unexpired token within minutes, up to about 15 minutes. For applications that do not support it, the user loses access when the access token expires. Orbitra's receipt therefore reads: refresh tokens revoked and new token issuance blocked now; existing access tokens expire within their lifetime, sooner for CAE-enabled apps. See containment verification for the full state model.
Step 7: the evidence receipt
Every response produces an attributable evidence receipt. It carries four timestamps (signal observed, plan ready, action submitted, provider verified), the before-state captured for each step, the exact paths removed from the blast radius, what remains reachable, what was restored, and who or what authorized every action. Each export carries a SHA-256 content fingerprint. A receipt covers one incident; an evidence pack collects a set. Both are designed to support audit and insurer review, and containment time is proven per incident in your own tenant, not marketed as a number. See cyber insurance evidence for how a receipt supports an insurer's questions.
Where Orbitra fits
Orbitra works alongside Microsoft native controls and owns the governed response and evidence layer between detection and directory recovery. It is built for lean security teams without a dedicated identity specialist, works at any Microsoft license level, and connects read-only in minutes with nothing acting without approval. To see the loop run against a test tenant, request a demo, or read how small security teams use it.
Related reading
- Privileged identity response: the category definition.
- What to do when an Entra admin account is compromised: the manual version of this loop.
- PIM without P2: what to do when eligible assignments are not available to you.
- Trust: permissions, data residency, and what Orbitra stores.
- Plans and frequently asked questions.
- Browse all guides and the glossary.
Sources
- user: revokeSignInSessions (Microsoft Graph v1.0), checked September 2026.
- Revoke user access in an emergency in Microsoft Entra ID, checked September 2026.
- Configurable token lifetimes in the Microsoft identity platform, checked September 2026.
- Continuous access evaluation, checked September 2026.