How it works
From a vendor change to customer evidence, assigned work and a verified closure.
The workflow is the same for every change. What differs is the connector that reads a vendor's environment and the rule that says what evidence means exposure. This page describes it as it runs today, with the Microsoft 365 connector and the EWS consent rule as the example.
- Vendor changeAn announcement that can affect customers
- Approved ruleWhat evidence means exposure
- Customer evidenceRead from each connected environment
- FindingA classification per customer, with its evidence
- Remediation taskAssigned, tracked, done by your engineer
- Verified closureOnly after a later complete scan
Microsoft 365 Current coverage
Further vendors Added only once validated. None available yet.
Connection
Add the customer environment
Name the customer and the Microsoft tenant they use. Nothing is read yet.
Send the consent link
Impactfold generates a link to Microsoft's admin-consent page for the connector application registered for your deployment. You send it to an administrator in the customer's tenant who can grant tenant-wide consent, usually a Global Administrator. They need no Impactfold account and never see your workspace. The consent screen lists exactly the permissions declared on that registration; the security page lists what the pilot registration declares.
Verify the connection
Impactfold obtains an application token for that tenant and makes one read,
GET /organization, to confirm access works and that the directory which answered is the intended tenant. It runs no scan and can produce no Safe, Affected or resolved result.
Collection
Approve the exact rule version
An operator approves the exact rule version before it can scan customers. Until then it can run only against an environment marked as a test. Withdrawing approval stops customer scans. Technically, approval is bound to the SHA-256 hash of the rule definition, requires a named reviewer, and is written to the audit trail.
Scan
The operator starts a scan. The connector reads only what the approved rule needs and records the outcome of every request, including failures. For the EWS consent rule that means reading the Exchange Online service principal, the application-role assignments and delegated grants on it, and each application that holds a matching grant. That is at least three Microsoft Graph requests. More are needed when results run to several pages, when several applications hold grants, or when Microsoft asks the connector to retry.
Interpretation
Classify each customer
The approved rule turns the evidence into one classification per customer: Affected, Likely affected, Needs manual review, Safe for this change, or Unknown. If any required read was refused, stale, cut short or failed, the result is Unknown and the reason is recorded: permission denied, stale data or collection failed. A run that is interrupted before it can record a result records none. None of these outcomes can report Safe or close a finding.
Assigned work
Finding and task
A result opens or updates one finding for that customer and that change, with every evidence row attached. You create a remediation task from it, assign an owner and a due date. When the engineer has made the change, you mark the task ready for verification. That records intent; it closes nothing.
Verification
Verifying scan
Run the scan again. If the read is complete and the exposure is gone, the scan engine closes the finding and the task together and records which run did it. The original Affected result and its evidence are never rewritten. A later Safe scan does not change which run closed it, and a returning exposure reopens both.
Validation note
EWS consent rule v2 in Advina Labs' Microsoft test tenant, 16 September 2026.
A controlled test of the full sequence (finding, human remediation, re-scan, closure) against real Microsoft Entra data. It is published so that anyone evaluating Impactfold can see exactly what was shown and what was not.
- Configured
- Advina Labs' own Microsoft 365 test tenant was added as a customer environment in a separate rehearsal workspace. The Impactfold connector already held admin consent in that tenant; the connection was verified at 07:03Z. Rule v2 was approved in that rehearsal workspace only; this is not a pilot approval. A test application in the tenant had the EWS application permission
full_access_as_appconfigured but not consented. A baseline scan at 07:04Z completed: Safe for this change, no finding. - Changed
- Two tenant changes, both made by an operator in Microsoft Entra and timed from its audit log: admin consent for
full_access_as_appgranted to the test application at 13:22:30Z, then revoked at 13:41:29Z. Neither was customer onboarding; the connector's own access was not touched. - Observed
- 13:33:14Z: a product scan completed Affected and opened a finding, with an evidence row naming the test application, the permission and the grant type. 13:34:26Z: a task was created and marked ready for verification; the finding moved to awaiting verification and nothing closed. 13:52:52Z: a scan started 11 minutes after the revocation completed Safe and closed the finding and the task, both attributed to that run and to impactfold.scan-engine. 15:43Z: a further scan was also Safe and did not change which run closed the finding.
- Verified
- An independent Azure CLI read at 13:33:52Z agreed with the Affected evidence field by field; another at 15:44:04Z found no EWS application-role assignment. The stored Affected result and its evidence were byte-identical before and after closure. A separate command-line check at 13:32:42Z, which stores nothing, also reported Affected.
- Requests
- Each scan here needed three Microsoft Graph requests, plus one lookup of the test application while it held the grant. In general the count depends on how many applications hold grants, pagination and retries, plus the sign-in discovery and token requests that precede them.
- Timing
- About 11 minutes from revocation to the closing scan. That is an observation from this run, not a guarantee of how fast Microsoft replicates a change or how long onboarding takes. The rule's guidance is to wait at least two hours before a verifying scan; the product does not yet enforce that. A scan that still reads a removed grant keeps the finding open; it cannot close it early.
- What this validates
- On the code that ships: the rule detects an EWS application-permission grant, the finding carries the evidence, a task cannot close anything, and only a later complete scan closes the finding and task, without rewriting the original result.
- Limits
- One run, in the provider's own test tenant; no customer tenant has been scanned yet. Provider sign-in to Impactfold was simulated in this run; every Microsoft read was real. Delegated EWS grants, multi-page results, throttling and the manual-review paths were not exercised live. The rule observes consent, not EWS usage, and does not read Exchange Online RBAC for Applications.
Vocabulary
Seven words, used precisely.
- Change
- A published vendor announcement that can affect customer environments, such as the retirement of Exchange Web Services in Exchange Online.
- Rule
- The detection logic for one change: which evidence to read and what makes a customer Affected. Versioned, and approved version by version.
- Scan
- One run of an approved rule against one customer environment.
- Finding
- The persistent record of one customer's state for one change, with its evidence and every transition.
- Safe for this change
- The approved check completed with fresh, complete evidence and found no exposure within the rule's scope. Never a statement that the environment is secure overall.
- Unknown
- The evidence was insufficient to decide, with the reason recorded. A legitimate result, never counted as safe.
- Verified resolved
- A finding that a later complete scan found clear, closed by the scan engine and attributed to that run.
Want to run this against customers you manage?