Orbitra is identity exposure and response software for identity and security teams in regulated mid-size enterprises running Microsoft Entra ID and Azure. It helps answer which access to fix, why a signal matters, and what changed after an approved response, in a record that holds up in front of auditors and regulators. The loop has four stages: detect, investigate, respond, record. Follow the interactive example, or read the four stages below.
1. Detect: map the access and find the signal
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 twelve Microsoft Graph read permissions. Response uses a separate action application with its own consent. See the exact permissions and consent model.
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.
Alongside standing exposure, Orbitra runs identity posture checks and event-driven detections. Depending on available telemetry, signals include unexpected role grants, risky app consent, password-spray patterns, unusual sign-ins, legacy authentication, and device-code activity.
2. Investigate: turn evidence into a proposal
The workflow separates standing exposure from signals needing investigation and from evidence supporting a response. A privileged identity is not necessarily compromised. Review the event context, access, and available corroborating signals before choosing an action. Automatic investigation is on by default for every connected workspace, read-only ones included, and a workspace administrator can turn it off. The AI reads the evidence and suggests catalog actions; it does not act by itself and does not authorize execution.
An investigation ends in a specific proposal. 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.
3. Respond: approve, execute, verify
In plan mode, Orbitra prepares the proposed action and your team acts. In approval mode, a named person approves before Orbitra executes. Policy, target validation, and action-specific permission checks govern execution. Every severity starts in approval mode. Only disabling a user or an application can run automatically, and only when your workspace sets that severity to respond automatically and Orbitra's platform controls allow it.
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, and the approval record travels with that specific target and action.
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.
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.
4. Record: keep the decision and the result
The response record 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 evidence packs. 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.