How HawkView accesses and protects your data.

HawkView requests read scopes and does not modify your customers’ users, groups, policies, mailboxes or files. There is no agent to install and no mail is rerouted.

Optional Exchange mailbox enrichment uses a separate permission you grant only if you want it, restricted by an Exchange role that exposes a single read cmdlet.

There is exactly one action HawkView performs against a customer tenant: it switches on Microsoft’s own activity feed so the unified audit log can be read. We call it out rather than leaving it inside a general “read-only” claim, because it is a write and you should know about it.

Microsoft Graph and the Office 365 Management Activity API, with optional read-only Exchange mailbox enrichment. Sign-in coordinates for the map are resolved on our own servers from a local geolocation database, so no customer IP address is sent to a third party for that lookup.

The map itself is drawn with third-party tiles, which means the browser viewing it contacts those tile providers. That is the operator’s browser, not your customer’s data.

Access is granted by administrator consent, and that consent is the switch. Withdraw it and HawkView can no longer read anything — though it will keep trying on schedule and recording the failure until you remove the tenant, which is also what deletes the evidence it holds.

Two things remain in your customer’s tenant until an administrator removes them — the Entra application entry, and Microsoft’s activity-feed subscription. Neither collects anything once consent is withdrawn. Removing a tenant deletes the evidence HawkView holds for it; workspace-level audit and alert records, which are keyed to your workspace rather than to the customer, are kept on their own schedule.

Collected sign-in, directory audit and administrative evidence carries a six-month expiry, and expired records are deleted during that customer’s next successful collection. Identity findings carry a ninety-day expiry and stop being served once it passes. Ask us for the current state of physical deletion before a pilot — we will not claim a retention guarantee we cannot evidence.

A newly connected tenant does not arrive with six months of history: HawkView backfills about thirty days from Graph. The Management Activity feed starts from the previous day and reaches back at most seven days when catching up, because that is all Microsoft’s content API exposes. It accumulates from there.

Most of the product works without premium Entra licensing. Graph sign-in logs and conditional access need Entra ID P1 or P2, and Identity Protection risk needs P2. Registration coverage prefers the premium report and falls back to a per-user read without it.

Where sign-in logs are gated, HawkView falls back to sign-in events in the tenant’s audit log. That is a narrower record and it is labelled as such: you get who signed in, from which address and roughly where, but not the conditional access result, the risk level, the device or the authentication detail — and only the last seven days.

The operating model is pilot-grade and there is no production service level. Collection runs on a schedule with capacity limits, and if it stops, screens keep showing the last thing they knew rather than raising an alarm — which is why every panel carries the time of its last successful collection.

Coverage is not guaranteed. Microsoft’s content API exposes at most the previous seven days, audit ingestion is capped per tenant per day, and Activity Logs shows the 5,000 most recent sign-in records and the 5,000 most recent audit records for the selected customer.

Alert email delivery is not a general feature. Several parts of the identity engine run in shadow mode or behind flags that are off by default. If a capability matters to your evaluation, ask us whether it is switched on rather than assuming it is.

Two boundaries, doing different jobs. The workspace boundary separates your MSP from every other: the API resolves each request to your signed-in identity’s active membership and scopes every query to your workspace — the browser never asserts which workspace or role it has. Cross-workspace access is covered by negative tests against a real database.

Inside your workspace, the customer boundary separates your customers from each other: every stored record is keyed to both the workspace and the customer tenant by a composite database key, so a record cannot reference a tenant in another workspace even by mistake. The deliberately cross-customer views — the priority queue, the risk matrix and What Changed — span your own customers and only ever your own.

A workspace belongs to an MSP team, not to one person. Each member signs in with their own account and their own multi-factor authentication — there is no shared login — and carries one of four roles: owner, administrator, technician or viewer. Membership is what grants access.