Security review

Security and assurance boundary

What Orbit controls, what the Microsoft tenant controls, where client-side enforcement stops and which evidence should be collected for an assured deployment.

Security & compliance9 min readAssurance position

A shared security boundary

Orbit is one component in a wider customer-controlled system. The product supplies application code, configuration patterns, schema, validation and implementation guidance. The deploying organisation controls identities, Microsoft tenant policy, SharePoint access, Power Platform governance, hosting, monitoring and operating processes.

A secure result therefore depends on the reviewed deployment—not on a product label. Assurance should trace every material control to an owner and a testable source of evidence.

Where access is enforced

Interactive API calls use delegated Microsoft identity. SharePoint permissions and item-level access are the default data-enforcement layer. UI routes, role labels and hidden controls are not authorization guarantees.

Where a requirement cannot be safely satisfied by SharePoint authorization alone—such as a high-risk pre-create decision—use an authenticated same-origin control service or an equivalent tenant-side workflow that validates the operation before writing.

ControlPurposeSecurity standing
Client-side route guardImprove navigation and prevent accidental actionUX control only
SharePoint site/list/item permissionRestrict data accessAuthoritative within the configured tenant model
Entra Conditional AccessControl sign-in conditionsAuthoritative identity policy
Authenticated server-side validationEnforce strict write rulesAuthoritative when designed and operated correctly
Power Automate conditionRoute and execute workflow logicOperational control; protect owners and connections

Permissions and consent review

The current reference application uses delegated scopes selected from User.Read, Sites.Read.All, Sites.ReadWrite.All, User.Read.All, GroupMember.Read.All, Mail.Send and Mail.Send.Shared according to enabled capability. Some permissions require administrator consent. The deployment owner must confirm the minimum set actually required and document why each scope is accepted.

Background publishers and other app-only workloads are separate identities. They should use narrowly scoped permissions such as Sites.Selected where the integration supports it, with explicit site grants and independent credential lifecycle controls.

  • Map each scope to a feature and test that disabled modules do not request unnecessary access.
  • Record consent authority, date, application owner and review cadence.
  • Separate interactive delegated access from background app-only access.
  • Review guest, shared-mailbox and group-directory scenarios explicitly.

Evidence expected before go-live

The implementation-assurance checklist is the starting control record. The final evidence must come from the customer’s configured environment.

  • Threat and data-flow review covering browser, static host, Microsoft APIs and optional services.
  • Permission inventory and positive/negative access tests for each role.
  • Secret scan and proof that no credential entered the client bundle or source branch.
  • DLP, malware, retention, audit, backup, recovery and continuity decisions.
  • Vulnerability response, dependency maintenance and controlled-release ownership.
  • Monitoring and incident runbooks for Microsoft, hosting and workflow failures.

What this documentation does not claim

Orbit is not represented as independently secure, compliant, certified or sufficient to establish an information-security or service-management system. Alignment material describes where the product can support controls and evidence when the deployment and operating model implement them.

Sources and deeper reading