Know what the platform handles before you grant access.
BridgeAD separates migration content, orchestration metadata, secrets, and execution responsibilities so security and delivery teams can review the real boundary.
Content moves between systems of record.
Mail, file, and message bodies are intended to stream from source to destination and are not retained at rest in BridgeAD infrastructure. The control plane stores the metadata needed for configuration, orchestration, error handling, reporting, and audit.
Migration content
Directory attributes and approved workload content read from the source for migration execution.
- Processed only for requested operations
- Not used for model training
- Cloud content transfer availability is workload dependent
Operational metadata
Job state, configuration, identifiers, findings, error counts, and audit records used to operate the service.
- Persisted according to customer policy
- Tenant-scoped access controls
- Export and retention requirements agreed during onboarding
Secrets
Credentials and tokens required to connect approved systems.
- Azure Key Vault for SaaS
- Protected stores for self-hosted deployments
- Tokens are not intentionally logged
Implemented safeguards and operating expectations.
Controls are effective only when the customer configuration, identity model, network boundary, and operational procedures are reviewed together.
- Transport
TLS 1.2 or later for external service traffic. - Tenant isolation
Application query filters and database row-level controls in multi-tenant deployments. - Privileged access
Five role tiers with MFA expected for privileged roles. - Session response
Disabled users are signed out and associated refresh/reset tokens are cleared. - Audit verification
Hash-chain verification and database protections for audit records. - Role-change traceability
Administrative role changes are recorded and surfaced as security notifications. - Observability
Health, metrics, OpenTelemetry, and alert integration are supported. - Secure delivery
CI build, test, and security gates are required before release promotion.
SaaS and self-hosted are different responsibility models.
They share an orchestration approach, but feature availability, infrastructure ownership, backups, monitoring, updates, keys, and network egress must be documented for the selected model.
| Responsibility | Managed SaaS | Self-hosted |
|---|---|---|
| Control-plane infrastructure | Operated by APQOR in Azure. | Operated in customer-managed Azure, Kubernetes, or Docker infrastructure. |
| On-premises agent host | Customer-owned. | Customer-owned. |
| Customer identity and consent | Customer-approved and administered. | Customer-approved and administered. |
| Secrets and key stores | Azure Key Vault under the service design. | Customer-deployed protected store and operational process. |
| Cloud API egress | Required for enabled Microsoft cloud workloads. | Still required for enabled Microsoft cloud workloads; self-hosted does not imply air-gapped M365 operation. |
| Backup and restore | Defined by service order and operating policy. | Customer and APQOR responsibilities must be agreed during deployment. |
Procurement materials
Request the DPA, current sub-processor information, architecture review, and security questionnaire response. Public trust materials will expand as independent assurance is completed.