The right action.
The exact identity.
A recorded result.
Removing a role, disabling a user, and revoking a grant solve different problems. Orbitra helps your team review a targeted response, approve it by name, and check the supported change in Microsoft.
Microsoft executes the change.
Your team owns the decision.
Orbitra invokes supported Microsoft Graph or Azure actions after named approval. Availability depends on the action, tenant configuration, and consented permissions. Review the exact scope and recovery information before execution.
What can Orbitra respond with?
Representative supported actions. Expand an action to see what changes and what verification can establish.
Privileged accessRemove an admin role
An unauthorized or unnecessary direct Global Administrator assignment gives an identity access it should not retain. Review the assignment and approve its removal.
- Action
- Remove the targeted direct role membership through Microsoft.
- Verification
- Read the relevant role membership again and check that the direct membership is absent.
- Recovery and limits
- Eligible role removals may be restored within the supported undo window. Other roles, group paths, and issued tokens need separate review.
User accountDisable a user account
When an investigation calls for blocking an account, approve a change to the specific user's enabled state. Consider the operational impact on the person and any dependent processes.
- Action
- Set the targeted Microsoft user's account to disabled.
- Verification
- Read the account's enabled state from Microsoft and check that it is disabled.
- Recovery and limits
- The catalog includes an enable-user action. A disabled account state does not prove that every issued token or application session has stopped working.
User sessionsRevoke user sign-in sessions
Use the Microsoft user-session revocation action when the response calls for invalidating the user's existing sign-in session state. This action applies to users, not service principals.
- Action
- Request sign-in session revocation for the targeted user.
- Verification
- Check that Microsoft's session-valid-from timestamp advanced relative to the response start.
- Recovery and limits
- Revocation cannot be undone. Propagation and application behavior matter; this timestamp is not proof that every active session or token has ended.
Application accessRemove an OAuth consent grant
When an application has a consent grant that should not remain, review the application, resource, and grant before approving the targeted removal.
- Action
- Delete the specific OAuth permission grant through Microsoft Graph.
- Verification
- Read the grant again and check that it is absent.
- Recovery and limits
- Review the action's recovery contract before approving. Other grants, app-role assignments, and already issued tokens remain separate concerns.
Workload identityRemove service-principal credentials
A workload response needs an action appropriate to that workload. The service-principal credential removal remedy removes its password and key credentials; review dependent services before using it.
- Action
- Remove the targeted service principal's password and key credential collections.
- Verification
- Read both credential collections and check that both are empty.
- Recovery and limits
- Credential removal cannot be undone and can interrupt applications. Replacement credentials and application recovery require a deliberate plan. Other identity objects and issued tokens need separate review.
Azure accessRemove an Azure role assignment
Review an Azure role assignment's principal and resource scope before proposing removal. Azure inventory and supported Azure actions are separate from the current Entra privilege-path analysis.
- Action
- Delete the specific Azure RBAC role assignment when the integration and direct-write permissions support it. Otherwise, the workflow may provide guided instructions.
- Verification
- Check the targeted assignment through Azure Resource Manager and record the supported result.
- Recovery and limits
- Review recovery support for the exact action. Other assignments and inherited access may still grant access to the resource.
Keep acceptance and verification separate.
A successful request tells you Microsoft accepted the operation. Verification checks the relevant state afterwards. Pending, failed, or unsupported checks should stay visible in the record.
Inspect an illustrative response recordStart without write access.
A read-only assessment cannot execute these actions. Response uses a separate action application and requires named approval.
Review the consent and permissions modelBring the scenario your team needs to handle.
Walk through the proposed action, the approval, and the evidence with a founder. Use a demonstration tenant before considering a connection to yours.