Security and data
Platform safeguards, then exactly what the Microsoft 365 connector asks for.
Send this page to the customer's administrator before they grant consent. It describes the product as it is today, for a supervised pilot, and claims no certification we do not hold.
Part 1 · Every connector
Platform safeguards
- Read-only
- Connectors request read permissions only, and the product has no code path that writes to a customer environment. Remediation is done by your engineers under their own access.
- One deployment per provider
- Each provider's workspace runs in its own deployment: one container and its database. It is not a shared multi-tenant service, so one provider's customer data is never stored alongside another's.
- Credentials outside the database
- Connector credentials are held in the server's environment configuration, in a file readable only by the service. The database has no column for a secret, token or refresh token. Access tokens are requested per operation and never stored.
- Evidence tied to the right tenant
- The tenant a read belongs to is established from Microsoft's own sign-in authority for that tenant, and the connection check confirms that the directory that answers is the intended one. Evidence cannot be attributed to a different customer environment.
- Approved rules only
- An operator approves the exact rule version before it can scan customers. Unapproved rules run only against environments marked as tests.
- Incomplete is never Safe
- A refused, stale, truncated or failed read produces Unknown, with the reason recorded. An interrupted run records no result. Neither can report Safe or close a finding.
- Closure only by scan
- No person can mark a finding resolved. Only a later complete scan that no longer finds the exposure closes it.
- Audit trail
- Every scan, approval, finding transition and task change is recorded with its actor and time. Entries cannot be edited.
- Workspace access
- Operators sign in with their Microsoft work account. Signing in grants nothing by itself; an administrator grants each person access to the workspace.
Hosting, backups and retention
- Who operates the host
- For a pilot, Advina Labs sets up and operates the deployment, its DNS, HTTPS and backups, unless the pilot agreement says the provider hosts it. The host's operator has administrative access to the host and the data on it. No pilot deployment exists yet; the hosting provider and region are chosen with each pilot.
- Network
- The deployment is reached only over HTTPS, through a reverse proxy in front of the application.
- Backups
- Database backups are encrypted with GnuPG public-key encryption before they are copied off the host, and the host holds only the public keys. Backups are kept for 30 days, and the newest seven are always kept. The off-host backup destination is set up for each pilot deployment and is not yet in operation.
- Retention
- The product does not yet enforce an automatic retention period. Scan records and findings are kept for the life of the deployment. Disconnecting a customer stops all reads but keeps its recorded results.
- Deletion
- When a pilot ends, deletion of the deployment, its database and its backups is agreed in the pilot agreement and done on the provider's instruction.
Part 2 · The current connector
Microsoft 365 connector
Which application you are consenting to
The connector is a multi-tenant Microsoft Entra application registered for each pilot deployment. Its display name and application (client) ID therefore vary by deployment. Before any consent link is sent, you receive both in writing. Verify them twice:
- On Microsoft's consent screen, before approving: the application name and the permission list must match what you were sent and the table below.
- Afterwards, in Microsoft Entra admin center → Enterprise applications: the application ID of the new entry must match the one you were sent.
The application is not publisher-verified, so Microsoft labels it unverified. That does not prevent an administrator granting consent, but it is why checking the application ID matters.
Permissions requested
| Permission | Type | Used for |
|---|---|---|
| Organization.Read.All | Application, read-only | Verifying the connection: one read of the tenant's id, name and verified domains. |
| Application.Read.All | Application, read-only | EWS check: the Exchange Online service principal, the application-role assignments on it, and each application holding a matching grant. |
| Directory.Read.All | Application, read-only | EWS check: delegated permission grants on Exchange Online. Microsoft documents this as the least-privileged permission for that read. |
Access is application-only: the connector authenticates as itself using the client credentials flow, and no user signs in on the customer's behalf. No mailbox permission, no write permission, no delegated permission is used by the connector.
The consent link asks Microsoft for the connector's /.default permissions, meaning every permission declared on the registration. Impactfold does not add permissions at run time, and it does not check whether a registration declares more than it needs. That is why the consent screen is the place to check: if it lists anything beyond the three permissions above, do not approve, and tell us.
What an EWS consent scan reads
- The Office 365 Exchange Online service principal, found by its well-known application ID.
- The application-role assignments on it, page by page.
- The delegated permission grants on it, page by page.
- For each application holding an EWS permission, its service principal: application ID, owning tenant and enabled state.
That is at least three requests per scan; pagination, several holders and retries add more. Nothing else is read: no mailbox, no message, no file, no sign-in log, no user list.
What is stored
- Directory metadata
- Service principal and grant identifiers, permission names, the display name, application ID, owning tenant and enabled state of each holder.
- Scan records
- Each run, each request's outcome, the classification, its completeness and the evidence rows the rule evaluated.
- Findings and tasks
- One finding per customer per change, its transitions, and any remediation task you create.
- People
- The sign-in identity of workspace operators, task owners you enter, and the actor of each audit entry. Nothing about a customer's end users.
- Never stored
- Mailbox content, messages, attachments, files, sign-in logs or user directories.
What the EWS check cannot see
- Usage
- It observes consent recorded in Microsoft Entra, not whether an application still calls EWS. Microsoft Graph does not expose EWS traffic; Microsoft's EWS usage report does.
- Exchange RBAC for Applications
- Exchange Online can grant EWS access to an application through the Application EWS.AccessAsApp management role. Those assignments are made in Exchange, not in Entra consent, and the check does not read them. A Safe result or a closure does not rule out EWS access granted that way.
- Tenant EWS controls
- It does not read the tenant's EWSEnabled setting, its EWSAllowedAppIDs allow list, per-mailbox EWS settings, or legacy EWS application access policies.
- Clouds
- Microsoft's global cloud only. National clouds are not supported.
Disconnecting and revoking
- Disconnect in Impactfold
- Stops every token request and scan for that customer and cancels outstanding consent links. Recorded results are kept. It does not remove the application from the customer's tenant.
- Revoke in Microsoft Entra
- The customer's administrator removes the connector application under Microsoft Entra admin center → Enterprise applications. That withdraws consent at the source, and only the customer can do it. After that, the next connection check or scan fails, and is shown as failed rather than as safe.
What Safe means
What we do not claim
No SOC 2, ISO 27001 or other third-party attestation. No penetration test report. No Microsoft publisher verification. These are stated plainly so that nobody has to ask, and they are fair questions for a pilot call.
Security researchers: a security.txt file gives a contact address and points to this page.
Questions administrators ask
Where is the credential, and how long do tokens live?
The connector's client secret is held in the server's environment configuration, never in the database. For each operation Impactfold requests a short-lived application token from Microsoft and discards it afterwards; tokens are not cached or written anywhere.
Can consent be limited to some users or mailboxes?
No. These permissions are directory-wide by Microsoft's design, and all three are read-only. Impactfold reads only the objects listed above. It has no mailbox permission to scope.
What will I see in my Entra portal after consent?
One enterprise application with the name and application ID you were sent, the three permissions in the table above, and the date and administrator who granted them. Removing it revokes the connector's access.
What happens to the data when the pilot ends?
Deletion of the deployment, its database and its backups is agreed in the pilot agreement and carried out on the provider's instruction. Until then, disconnecting a customer stops all reads while keeping its recorded results.
Something this page did not answer? Ask, and the answer will be added here.