Identity threat detection and response for Microsoft Entra ID and Azure. Find dangerous access across users and applications. Approve a targeted action. Orbitra executes it in Microsoft and verifies supported changes.
Start with a demonstration tenant. Connect read-only when you choose. By default, a named person approves every Orbitra-executed response.
For identity and security teams in regulated mid-size enterprises who must show auditors and regulators who holds privileged access, what changed, and who approved it.
By operators with experience at Los Alamos, MITRE, and Morphisec.
The person on call needs to know what is exposed, which action fits, and whether the response changed what it was meant to change.
Establish how the identity gained access. Review the direct assignment and supported privilege paths, then decide which access should be removed.
See the targeted role-removal responseInvestigate the workload identity and its permissions. Choose a response for its grant or credentials, with the impact on dependent applications in view.
See application-access responsesKeep the approver, exact target, provider outcome, and verification together. Explain the change and what still needs review after the incident.
See what the response record establishesAn unauthorized admin grant becomes a targeted, approved response. Follow the handoffs all the way to the record.
Example incident Unexpected Global Administrator grant
Illustrative workflowAn unexpected Global Administrator grant is attached to Jordan Lee. Orbitra brings the identity and event evidence into the investigation.
Privilege alone is not proof of compromise. This example starts with an unexpected grant.
The reviewer establishes that the assignment is unauthorized. Orbitra prepares a targeted role removal with the evidence, exact target, and recovery details.
Access analysis and proposed fixes provide context before anyone acts.
Remove Jordan Lee's direct Global Administrator assignment. Alex Morgan is the named example approver. The proposal stops here until you approve it.
This button approves an illustration. It does not connect to a tenant or change a real account.
The approved response passes policy, target, and permission checks. Orbitra then calls Microsoft Graph to remove the direct role membership.
The responder performs a real provider action in the product. This animation uses example data.
Orbitra reads the relevant role membership back from Microsoft. The expected outcome is that this direct Global Administrator membership is absent.
That verifies this removal. Other roles, group paths, sessions, and tokens still need their own checks.
The response record brings together the before-state, named approval, provider outcome, and verification. Your team can inspect the same evidence after the incident.
The sample is illustrative. Integrity checks do not provide independent attestation or certify compliance.
Explore the product from detection to recordA named person authorizes execution. No live actions in this illustration.
By default, Orbitra carries out supported Microsoft actions after named approval. Choose the response that matches the identity and the problem.
Remove a targeted direct role membership. Read Microsoft again to check that the membership is absent.
Review the action and its scopeChange the account's enabled state and verify it in Microsoft. Review the impact and any remaining session access.
Review account disablementRequest user-session revocation and check Microsoft's session-valid-from timestamp. Application behavior and propagation still matter.
Review session revocationDelete the targeted OAuth consent grant and verify its absence. Other grants and issued tokens require their own review.
Review grant removalAlready using Defender, Entra ID Protection, or PIM? Orbitra connects identity context and its own detections to an approved action and evidence of the supported result.
Review human and workload access, supported Entra privilege paths, and available identity signals in context.
Review the exact target and permissions. By default, a named person approves before Orbitra invokes the supported Microsoft response.
Keep provider acceptance separate from verification. Retain the decision and the outcome for incident follow-up and access reviews.
Assessment uses a separate read-only application. Review your exposure before considering response permissions.
Read the permissions and trust detailsAdmin consent to twelve Microsoft Graph read permissions. Azure inventory also depends on the Azure access you configure.
Inspect the exact target, scope, reversibility, and available verification. Your team can keep Orbitra in plan mode.
Execution uses a separate action application. Microsoft consent grants that app's configured permissions; policy and action-specific checks govern each response, with named approval by default.
Give the next reviewer, auditor, or regulator the same record: the available before-state, named approval, action result, and verification. Make the specific outcome and any remaining uncertainty clear.
Inspect an illustrative evidence recordBefore and afterThe specific state the response was intended to change.
Decision and attributionA named approver, action target, and recorded outcome.
Verification with boundariesConfirmed change, pending verification, and remaining access kept distinct.
Integrity checksSHA-256 supports file checking. It does not certify compliance.
A practical Entra ID hardening checklist for lean security teams: privileged role cleanup, service principal and OAuth risk, Conditional Access gaps, and what to monitor after setup.
Read the postEmployee count doesn’t predict identity risk. What matters is whether a team has a dedicated identity specialist. Here’s the test that actually applies to you.
Read the postOrbitra provides identity threat detection and response for Microsoft Entra ID and Azure. It brings access inventory, supported privilege-path analysis, and its own detections into an investigation, then executes named-approved responses and verifies supported changes in Microsoft.
Not by default. Every severity starts in approval mode, so an Orbitra-executed response waits for a named approver. In plan mode, your team acts. In approval mode, Orbitra executes the approved action after policy and permission checks. 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.
No. Assessment starts with a separate read-only application. Response requires separate consent to the action application and, by default, a named approval. Microsoft grants the permissions configured for that application; consent is not limited automatically to a single response pack.
Orbitra works alongside Microsoft Defender, Entra ID Protection, and PIM. It adds its own identity detections, access analysis, prioritized remediation, and an approved response workflow. Available telemetry and Microsoft features depend on your licenses and configuration.
For a supported action, Orbitra reads the relevant state back from Microsoft after execution. A removed role assignment verifies that specific change. It does not prove every access path or issued token is gone. Evidence distinguishes provider acceptance from verification.
Book a 30-minute walkthrough with a founder. Follow an investigation, review the proposed action, and inspect the result in a demonstration tenant. No connection to your tenant is needed.
Rahul or Leonard replies within one business day.
Prefer email? hello@orbitrasecurity.com