Deployment and network
- SaaS region or self-hosted infrastructure design
- Agent placement, directory paths, Microsoft API egress, and proxies
- Database, messaging, storage, secret, telemetry, and backup boundaries
Security
Know what the platform handles before you grant access.
BridgeAD separates migration content, inventory and orchestration metadata, secrets, tenant administration, customer-network execution, and Microsoft API access so security and delivery teams can review the actual boundary.
Certification statementBridgeAD does not claim SOC 2 or ISO certification on this site. Control descriptions below describe implementation and operating expectations, not independent certification.
Data 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
Data flow
Persist the state needed to resume and prove work.
BridgeAD does not treat all migration data the same way. Content bodies, assessment inventory, stable identifiers, progress state, tokens, findings, and audit records have different handling and retention purposes.
| Data category | Processing path | Persisted by BridgeAD | Review point |
|---|---|---|---|
| AD directory operations | Assigned agent reads or writes approved directory objects from the customer network. | Connection and object references, mappings, job and command state, findings, outcomes, and audit metadata. | Agent host, service identity, delegated privileges, LDAP/LDAPS and resource paths, command protection, and logs. |
| Microsoft 365 content | Approved source content is read and written through workload-specific Microsoft Graph paths. | Scope, item identifiers, counters, progress, delta state, conflict or error outcomes, and validation evidence; not mailbox, file, or message bodies at rest. | Application permissions, tenant consent, API egress, throttling, destination state, telemetry, and content-specific exclusions. |
| Assessment inventory | Configured discovery reads object and workload metadata needed to define readiness and scope. | Selected inventory, aggregate volume, findings, samples where configured, scope definitions, mappings, and remediation state. | Data minimization, assessment access, sample content, export handling, retention, and deletion requirements. |
| Secrets and tokens | Credential references are resolved only for approved connection and execution operations. | Secret references and configuration state; protected secret values live in the configured secret store. Access tokens are not intentionally logged. | Key ownership, secret rotation, managed identity or service principal design, backup, operator access, and incident response. |
| Audit and operations | Portal, API, worker, role, job, and security events emit operational and audit records. | Tenant-scoped audit entries, correlation identifiers, hash-chain data, status history, notifications, and exportable evidence. | Retention, export, SIEM integration, access review, time synchronization, and investigation procedure. |
Controls
Implemented safeguards and operating expectations.
Controls are effective only when the customer configuration, identity model, network boundary, Microsoft consent, 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 and customer-owned role assignment. - 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.
Deployment ownership
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. |
Review package
Bring the selected deployment and workload scope.
A useful security review maps product controls to the exact data, APIs, infrastructure, identity, and support model requested for the engagement.
Roles and consent
- BridgeAD operator roles, MFA, access review, and break-glass process
- AD service identities and delegated rights
- Graph applications, permissions, consent, credentials, and rotation
Retention and response
- Inventory, audit, report, log, and backup retention
- Monitoring, SIEM, alert routing, incident response, and support access
- Export, deletion, recovery, change, and release responsibilities
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.