Token Watch
No-persistence mode
Updated September 7, 2026
No-persistence mode removes the readable credential inventory from Token Watch’s database. It is for teams whose concern is the standing list itself: which applications matter, and when each credential is due for rotation.
What it changes
In this mode Token Watch stores no application names, credential names, start dates, expiry dates or owners. What remains is a list of opaque identifiers, the application id and the identifier of each credential, with no attributes attached.
Those identifiers are retained so that decisions already made still bind to the right credential: which credentials have tracking switched off, and which Azure DevOps work item corresponds to which credential. Without a stable key, both would reset on every run.
Everything else is read live from Microsoft Graph at the point it is needed:
- Scheduled check: reads App Registrations from Graph, evaluates expiry, sends the alert, and retains nothing from the response.
- Application list in the UI: built from a live Graph read, so it shows current tenant state rather than the last sync.
The permission is unchanged: the same read-only Application.Read.All against the same
single endpoint, described on the permissions page. Only the
handling of the response differs.
Stored in each mode
| Field | Standard | No-persistence |
|---|---|---|
| Application ids and credential identifiers | Stored | Stored |
| App Registration display names | Stored | Not stored |
| Credential display names | Stored | Not stored |
| Credential start and expiry dates | Stored | Not stored |
| App Registration owner object ids | Stored | Not stored |
Still stored
The mode applies to the credential inventory, not to the whole service. The following remain in both modes.
| Retained | Reason |
|---|---|
| Application ids and credential identifiers: key id for a secret, thumbprint for a certificate | The key that per-credential tracking and Azure DevOps work item links attach to. No name, date or status is stored against them. |
| Tenant id, consent state, timestamp of the last check | Required for the account to exist and for the schedule to run. |
| Users: email address, Entra object id, role, status, last sign-in | Access control. Approval of who may sign in has to survive a restart. |
| Monitoring settings: expiring threshold, lookback, reporting on/off | Configuration the next run reads. |
| Alert recipients, and webhook or Azure DevOps configuration if used | Delivery destinations for the alert. |
| Billing record: billing email, identifiers issued by Paddle or Microsoft | Required to operate a paid subscription. |
| Audit log entries: actor and timestamp per settings change | Accountability for changes to alerting configuration and access. |
| Application logs: timestamps, request paths, tenant ids, error traces | Operations. They identify the tenant, not its applications. Retained under the policy on the retention page. |
Trade-offs
- Every view is a live Graph call. The application list waits on Graph rather than the database, page by page for large tenants, so latency scales with the number of App Registrations.
- There is no fallback during a Graph outage. Standard mode shows the last known state and retries the sync; with no stored inventory there is nothing to display.
- Tracking and Azure DevOps linking still work. Disabled tracking persists, and a work item is raised once per credential rather than on every run.
Enabling it
No-persistence mode is configured per tenant. Email contact@aztokenwatch.com if you would like to enable it.
If the constraint is data location rather than the inventory itself, the EU-hosting option on the architecture page may be the better fit. combined.
Related
- What data Token Watch holds — the standard-mode inventory this option removes.
- Permissions and Graph access — identical in both modes.
- Architecture, hosting and encryption — including EU data residency.