Orbitra is identity exposure and response software for teams managing Microsoft Entra ID and Azure. It helps answer which access to fix, why a signal matters, and what changed after an approved response. Follow the interactive example, or read the six stages below.
1. Map human and workload access
Connect through a read-only enterprise application to collect users, groups, devices, app registrations, service principals, OAuth grants, and directory roles. Azure RBAC inventory adds cloud role assignments where Azure access is configured. Managed identities belong in the same access review as human administrators. No endpoint agent is required.
The initial application requests eight Microsoft Graph read permissions. Response uses a separate action application with its own consent. See the exact permissions and consent model.
2. Prioritize supported Entra paths
Orbitra analyzes supported paths to privileged Entra roles: direct assignments, nested group membership up to three levels, application ownership, and ownership of role-assignable groups. Keystone ranks candidate access changes by the analyzed paths they remove and offers a what-if view before a change.
This is bounded exposure analysis. It is not proof of exploitation or an exhaustive map of every route to privilege. Azure RBAC escalation, PIM eligibility, delegated OAuth paths, and role-to-role escalation are outside the current Entra path engine. Inventory coverage is broader than path coverage. Read how Entra path prioritization works.
3. Investigate the evidence
Orbitra runs identity posture checks and event-driven detections. The workflow separates standing exposure from signals needing investigation and evidence supporting a response. Depending on available telemetry, signals include unexpected role grants, risky app consent, password-spray patterns, unusual sign-ins, legacy authentication, and device-code activity.
A privileged identity is not necessarily compromised. Review the event context, access, and available corroborating signals before choosing an action. Optional AI assistance can summarize supplied evidence and suggest catalog actions when enabled for the platform and tenant. It does not authorize execution.
4. Approve a specific response
In Recommend mode, Orbitra presents the proposed action and your team acts. In Approve mode, a named person approves before Orbitra executes. Policy, target validation, and action-specific permission checks govern execution. Autonomous execution is not available in production.
The response catalog includes supported user, application, directory-role, group, consent, and Azure actions. The reviewer sees the target, required permissions, and reversibility. Session revocation is a user action; it is not an action on a service principal. A compromised application needs actions appropriate to that application and its grants or credentials.
Some changes, such as supported directory-role or group membership removals, can be restored within the undo window, which defaults to 24 hours. Session revocation, password resets, and credential removals cannot be undone. Review the specific action contract before approval.
Orbitra executes the approved response in Microsoft
Approval leads to an actual provider action. Orbitra validates the response target, checks tenant policy and permissions, and invokes the corresponding Microsoft Graph or Azure API. Supported actions include disabling a user, revoking user sessions, removing directory-role or group membership, revoking an OAuth grant, and removing a workload credential. The action must match the identity type and its specific execution contract.
For the animated example, the response removes a user's direct Global Administrator membership. The approval record travels with that specific target and action. A provider accepting the operation is recorded separately from verification of the resulting state.
5. Verify the supported change
For supported actions, Orbitra reads the relevant state back from Microsoft Graph or Azure after execution. The record distinguishes the provider accepting the request from a later read confirming the intended state. Unsupported or inconclusive verification must not be treated as confirmed containment.
Removing one role assignment proves that assignment was removed. It does not prove that other roles, group paths, application permissions, or issued tokens are gone. Verification is scoped to the change being checked.
6. Retain evidence of the decision and result
Evidence ties the response to its before-state, named approver, action outcome, and available verification. Supported reports serve executive, security, and audit workflows, with formats depending on report type.
SHA-256 checks support integrity verification of exported content. They are not a digital signature, independent attestation, or compliance certification. Inspect the illustrative record from the walkthrough.
Works alongside your Microsoft controls
Keep Defender, Entra ID Protection, and PIM in your security program. Orbitra adds its own identity analysis and detections, then connects investigation to approved response and evidence. Business Premium, E3, and E5 teams can assess exposure; Microsoft licenses and configuration determine available telemetry and provider features.
Request a privilege exposure review to establish the coverage, permissions, and response scope for your tenant.