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. The "Before you connect" block on the homepage is repeated here word for word so the two never drift apart.
Before you connect
These are the eight facts we put in front of every prospective customer.
- Agentless. Orbitra connects through a Microsoft Entra enterprise application. 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 permissions live in a separate action application and are consented only when you enable a response pack, scope by scope, the narrowest Microsoft scope wherever one exists.
- The destructive user-delete scope is deliberately excluded from consent.
- Orbitra never stores user passwords. A forced reset is executed through Microsoft and the new credential is never held.
- Removing the enterprise application ends Orbitra's access. Console sign-in is Microsoft Entra SSO. Onboarding is invite-only.
- Tenant data stays in the region you choose at onboarding: United States (AWS us-west-2) or India (AWS ap-south-1).
- 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 eight scopes and nothing else.
| # | 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, MFA registration report |
| 08 | Device.Read.All | device inventory and compliance |
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 eight read scopes 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. It does not exist in your tenant until you enable a response pack.
How write scopes are consented, per response pack
Response permissions live in the action application and are consented only when you enable a response pack. Each pack lists the actions it contains and the exact Microsoft scope each action needs, scope by scope, before anything is granted. Across every pack Orbitra requests 11 fine-grained write scopes, the narrowest Microsoft scope wherever one exists. A pack you never enable never asks for its scopes, and the review and the pilot need no write scope at all.
Consent to a write scope is not permission to act. In Recommend mode, Orbitra proposes the response and your team executes it. In Approve mode, a named person signs off before Orbitra executes. Every customer tenant uses one of those two modes today, and Autonomous mode has never executed in a customer tenant. Every response comes from an allowlisted catalog of more than two dozen governed response actions and is pre-authorized by tenant policy, not decided by a model. Orbitra independently re-reads Microsoft after supported response actions to verify the final state; containment verification explains what that re-read checks.
The user-delete scope is excluded
The scope that would allow Orbitra to delete a user account is deliberately left out of consent. It is not in any response pack and is never requested. Containment in Orbitra disables accounts, revokes sessions, removes role assignments and consent grants, and removes credentials; it never deletes a user. 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). Orbitra tells you which steps are permanent before you approve them.
Disconnecting, signing in, and getting started
Removing the enterprise application ends Orbitra's access. If you have also consented to the action application, remove both. 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, no free trial, 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 tenant data lives
Orbitra runs in two production regions, United States (AWS us-west-2) and India (AWS ap-south-1), with immutable data residency. You choose one at onboarding and the choice is fixed: tenant data is stored and processed in that region and is not moved to the other.
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; fixed United States or India data residency; and SHA-256 fingerprinted evidence packs from every response, 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, GCP, or on-premises Active Directory.
- Detections arrive in minutes, not seconds. 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.
Where Orbitra fits
Orbitra works alongside Microsoft native controls and owns the governed response and evidence layer between detection and directory recovery. It is agentless and read-only in minutes; when you later enable Approve mode, a named person signs off before Orbitra executes. Every response produces an attributable evidence receipt. Orbitra is built for lean security teams without a dedicated identity specialist, at any Microsoft license level. See how it works, identity response on Business Premium and E3, and the FAQ.
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. The review and the pilot use eight read scopes only, granted through admin consent, and you can stay read-only indefinitely. Write scopes live in a separate action application and are consented only when you enable a response pack, scope by scope.
Can Orbitra delete users in my tenant?
No. The scope that would allow deleting a user account is deliberately excluded from consent. It is not in any response pack and is never requested.
Where is my tenant data stored?
In the region you choose at onboarding: United States (AWS us-west-2) or India (AWS ap-south-1). The choice is fixed and tenant data is not moved between regions.
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, fixed US or India data residency, and SHA-256 fingerprinted evidence packs.