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 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 uses a separately consented action application. Consent grants its configured permission set; policy and action-specific checks govern execution.
- 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.
- 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 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, consented separately when you choose to enable response.
Separate action consent and execution checks
Response permissions live in a separate action application. Its configured permission set includes read permissions and 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, action-specific permission checks, and a named human approval govern each Orbitra-executed action today. In Recommend mode, your team executes the proposed action; in Approve mode, Orbitra executes after approval. Autonomous execution is not available in production.
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 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 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 exportable response evidence 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, 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.
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. A named person approves every Orbitra-executed response today. 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 eight 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?
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?
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.