How we access your tenants, and what we keep
Written for the security review you’ll have to pass, not for a feature grid.
Authentication
Access to your tenants uses Microsoft's own consent model. There are no passwords to hand over and no service accounts to create.
- Certificate-based app-only authentication — no shared secrets in config
- Admin consent granted per tenant, by your Global Administrator
- Consent is revocable from your tenant at any time, without involving us
- Least privilege: only the Graph and Exchange scopes each workload needs
Data handling
Mail moves tenant to tenant. The platform is the mover, not a repository — content passes through and is not retained.
- Message content is streamed to the destination, never stored at rest by us
- We keep metadata: identifiers, counts, sizes, timestamps, job state
- Reconciliation stores Message-IDs — not message bodies or attachments
- Credentials and certificates live in Azure Key Vault, not application config
Residency and isolation
Each customer's migration data lives in its own database schema, in the region that customer selected.
- Schema-per-customer isolation — no shared migration tables
- Customer-region data residency, selected at signup
- Encryption in transit throughout; encryption at rest on Azure managed services
- Operator access is role-based and recorded in an audit trail
Auditability
Everything that happens to an object is recorded, so you can answer questions after the fact rather than reconstructing them.
- Per-object audit events with actor, action and timestamp
- Signed reconciliation report at cutover
- Signed rollback runbook generated for domain cutover
- Exportable reports for your own records and reviewers
Security review or DPA?
Binary Minds ITNS LLC is the contracting entity and issues the DPA, terms of service and SLA. If your review needs specifics — scopes requested, subprocessors, regions, retention — ask and we’ll answer them directly rather than pointing at a trust page.