Orbitra holds consented application access to your Microsoft Entra ID and Azure tenant. Before you grant that access you should be able to read exactly what is requested, where the data goes, how to take it back, and which claims we do not make. This page explains the access and processing details to review before connecting.
Before you connect
These are the eight facts we put in front of every prospective customer.
- Agentless. Orbitra connects through Microsoft Entra enterprise applications. Nothing is installed on endpoints or servers.
- Read-only first. The review and the pilot use read permissions only, granted through admin consent, and you can stay read-only indefinitely.
- Response uses a separately consented action application. Consent grants its configured permission set; policy and action-specific checks govern execution.
- The user-delete scope is never requested at consent. Deleting a user is possible only if your administrator grants that permission directly, with a typed confirmation, never automatically.
- Orbitra never stores user passwords. A forced reset is executed through Microsoft and the new credential is never held.
- Removing the Orbitra enterprise applications ends Orbitra's access once already issued tokens expire. Console sign-in is Microsoft Entra SSO. Onboarding is invite-only.
- Regional response and connection records use your workspace's United States or India home region. Shared ownership and authorization metadata and automatic application reports use US services. See processing locations.
- No SOC 2 report yet. We say so plainly, and we publish a vulnerability disclosure policy and a data use page instead of implying one.
The read-only consent asks for these twelve application permissions. The first eight are the inventory and log reads; the last four are capability reads for the response protection checks and the Entra ID Protection risk feed. The same application signs your team in, so it also carries the delegated scopes Microsoft requires for sign-in.
| # | Scope | What it reads |
|---|---|---|
| 01 | User.Read.All | user profiles, account status, sign-in metadata |
| 02 | Group.Read.All | groups, memberships, owners |
| 03 | Member.Read.Hidden | hidden memberships so inventory is complete |
| 04 | Application.Read.All | app registrations, service principals, credential metadata |
| 05 | Directory.Read.All | directory roles, role members, OAuth grants |
| 06 | RoleManagement.Read.Directory | role definitions and assignments, isPrivileged flags |
| 07 | AuditLog.Read.All | directory audits, sign-in logs |
| 08 | Device.Read.All | device inventory and compliance |
| 09 | Policy.Read.All | policy objects, for the response protection checks |
| 10 | PrivilegedEligibilitySchedule.Read.AzureADGroup | PIM for Groups eligibility schedules |
| 11 | PrivilegedAssignmentSchedule.Read.AzureADGroup | PIM for Groups assignment schedules |
| 12 | IdentityRiskEvent.Read.All | Entra ID Protection risk detections |
Write scopes are listed action by action during onboarding, before any consent is granted. Ask for the full list on the review call.
Two Entra applications: read, then action
Orbitra connects through two Microsoft Entra applications rather than one. The first is the read application. Consenting to it creates one enterprise application in your tenant carrying the twelve read permissions above. It runs without a signed-in user, so it uses application permissions. Microsoft Graph separates delegated access, where an app acts on behalf of a signed-in user and can never exceed that user's rights, from app-only access, where the app calls Graph with its own identity; an application permission reaches any data it covers, tenant-wide. That is why we list every scope with what it reads instead of summarizing them.
One scope deserves a note. Microsoft describes Directory.Read.All as the highest privileged read-only permission for Microsoft Entra ID resources and says to prefer lesser-privileged options where they exist. Microsoft's own least-privilege guidance offers it as the single alternative when an app needs to read all properties for all member object types (users, groups, devices, service principals). That is the inventory case for an identity graph, which is why the scope is on the list. Directory audit and sign-in data are read from the /auditLogs/directoryAudits and /auditLogs/signIns endpoints under AuditLog.Read.All; what the sign-in report contains depends on what your tenant has licensed.
Consent to application permissions happens when the application is installed in the tenant or through the Microsoft Entra admin center. Tenant app consent policies can restrict user consent even for permissions that do not need admin consent by default, so plan on admin consent for the read application. If the person connecting Orbitra cannot grant it, Microsoft's admin consent workflow lets them send a request to the reviewers your tenant has designated.
The second is the action application, consented separately when you choose to enable response. Where you want Exchange mailbox signals such as inbox-rule changes, a third application with the Office 365 Management ActivityFeed.Read permission is consented separately as well.
Separate action consent and execution checks
Response permissions live in a separate action application. Its configured permission set is the eight core read permissions plus 11 action permissions. Microsoft admin consent grants the configured application permissions; it does not automatically grant only the subset associated with one response pack. Review the consent screen and action application manifest before granting access.
Consent enables API access. It is not approval to execute a response. Tenant policy, target validation, and action-specific permission checks govern each Orbitra-executed action, and by default a named person approves it. In plan mode, your team executes the proposed action; in approval mode, Orbitra executes after approval. 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.
Orbitra re-reads relevant Microsoft state after supported actions. Verification of one assignment or grant is evidence of that specific change, not proof that all access is gone. See the response workflow and coverage limits.
The user-delete scope is never requested
The scope that would allow Orbitra to delete a user account is never requested at consent. Containment in Orbitra disables accounts, revokes sessions, removes role assignments and consent grants, and removes credentials. A delete-user action exists in the catalog for tenants whose administrator grants that permission directly in Entra; it requires a typed confirmation and never runs automatically. If you want the difference between disabling an account and revoking its sessions spelled out, read revoke sessions versus disable user.
Passwords are never stored
Orbitra never stores user passwords. When a response pack includes a forced password reset, the reset is executed through Microsoft and the new credential is never held by Orbitra. A password reset is also one of the steps that cannot be undone. Session revocation, password reset, credential removal, Azure role assignment removal and PIM changes are permanent. Entra directory role and group membership removals can be restored within the undo window (24 hours by default), except assignments managed by PIM. The plan marks which steps can be undone when it is built.
Disconnecting, signing in, and getting started
Removing the Orbitra enterprise applications ends Orbitra's access once already issued tokens expire. If you also consented to the action application or the activity feed application, remove those too. You can do this from the Microsoft Entra admin center at any time without contacting us. Data already synced is handled under the retention terms below.
Console sign-in is Microsoft Entra SSO. Your team signs in to the Orbitra console with the Entra accounts it already has, so there is no separate Orbitra password to create, rotate, or lose.
Onboarding is invite-only. There is no self-serve signup or free trial on this site, and no credit card flow. Every tenant starts with a review call, then a read-only connection, and stays read-only until you choose a response pack. Request a demo to start.
Where data is processed
Regional response and connection records use your workspace's United States (AWS us-west-2) or India (AWS ap-south-1) home region. Shared ownership and authorization metadata and the web application's automatic operational reports use US services. The data use page explains automatic reporting, processing locations and retention.
Retention in plain words: Orbitra keeps identity inventory, detections, incidents, and evidence for as long as the service needs them and your agreement allows. When data is no longer needed it is deleted, de-identified, or archived. Retention periods vary by data type, customer agreement, and legal requirement, and a customer agreement controls over anything on this page. The data use page covers what is collected from website visitors, demo requests, pilots, and customer-authorized security data, and the privacy policy covers personal data.
No SOC 2 report yet
Orbitra does not have a SOC 2 report or any other third-party attestation. We say so plainly rather than imply one.
What exists instead: this page, with every read scope named; a published vulnerability disclosure policy with scope, safe harbor, and response targets; a data use page; a minimal-consent posture with the read and action applications separated; documented regional storage and shared US processing; and evidence packs with SHA-256 integrity checks, designed to support audit and insurer review. If procurement needs more than this page, raise it on the review call and we will tell you what we can and cannot provide. If you find a vulnerability in Orbitra, the same disclosure page explains how to report it and what you get back.
What we do not claim
- Microsoft Entra ID and Azure only. No Okta, Google Workspace, AWS IAM, or GCP. Orbitra does not read on-premises Active Directory; for accounts synced from AD, an optional response can trigger a Microsoft Lifecycle Workflow your team builds, with permissions your administrator assigns directly.
- Detections arrive in minutes, not seconds. Orbitra polls Microsoft sign-in and audit logs every minute, and Microsoft's own log delivery can add up to about twenty minutes. Containment time is proven per incident in your own tenant, not marketed as a number.
- Not every action is reversible. Rollback where the provider action is truly reversible, otherwise a defined recovery path.
- Not every action is independently verified. Orbitra independently re-reads Microsoft after supported response actions to verify the final state; most changes are re-read and verified after execution.
- Orbitra is not a replacement for Microsoft's native controls. It works alongside them and owns the governed response and evidence layer between detection and directory recovery.
- Orbitra is software, not a 24/7 human security operations center.
- AI does not execute. AI can summarize evidence and recommend from the allowlisted catalog; deterministic policy owns execution.
- No production outcome metrics are published: no containment times, false-positive rates, uptime figures, or identity counts.
- Single-tenant today.
Orbitra connects Microsoft identity exposure analysis to approved response and evidence. It inventories human and workload access, prioritizes supported Entra privilege paths, and re-reads Microsoft state for supported actions. By default, a named person approves every Orbitra-executed response. Only disabling a user or an application can run automatically, and only when your workspace and Orbitra's platform controls allow it. See the workflow and coverage limits, or request a read-only exposure review.
Sources
- Microsoft Graph permissions overview (delegated versus app-only access, Directory.Read.All guidance, consent policies), checked September 2026
- Activity reports API overview, Microsoft Graph v1.0 (directoryAudits and signIns endpoints, license gate), checked September 2026
- Configure the admin consent workflow, checked September 2026
Frequently asked questions
Does Orbitra need write access to my tenant to start?
No. Assessment uses a separate application with twelve Microsoft Graph read permissions. Response requires separate consent to the action application. That consent grants the permissions configured for that app, with policy and action-specific checks governing execution.
Can Orbitra delete users in my tenant?
Not with the permissions Orbitra requests. The scope that would allow deleting a user account is never requested at consent. The catalog does hold a delete-user action, but it runs only if your administrator grants that permission directly in Entra, it needs a typed confirmation, and it never runs automatically.
Where is my tenant data stored?
Regional response and connection records use your workspace's United States (AWS us-west-2) or India (AWS ap-south-1) home region. Shared ownership and authorization metadata and the web application's automatic operational reports use US services. The data use page explains these processing locations.
Does Orbitra have a SOC 2 report?
Not yet. Instead, Orbitra publishes every read scope it requests, a vulnerability disclosure policy, a data use page, a separated read and action application design, documented regional storage and shared US processing, and SHA-256 fingerprinted evidence packs.