After an estate-wide password reset, which identity artefacts still let an intruder back in?

## The failure mode this question is about The estate is reset, everyone re-authenticates, the incident is closing, and on day three an authentication succeeds from infrastructure you have already blocked. Almost always the returning credential is one the adversary minted for themselves while they held privilege, precisely because it does not depend on any user's password. Enumerating that class of artefact is the substance of revocation in a modern identity estate. ## The classes to work through **Application consent grants.** A grant records that an application may act on a user's or the tenant's behalf with a set of scopes. The application then holds its own tokens, and a scope such as `offline_access` gives it a refresh token it can keep exchanging. Nothing about a password reset withdraws consent. Look for grants approved during the dwell window, especially mail-read, file-read and directory scopes, and for tenant-wide admin consent, which reaches every user at once. **Credentials on application and service identities.** An application registration or service principal can carry multiple client secrets, multiple certificates, and federated credentials that trust an external issuer. They are additive. Deleting the one secret you found in the logs leaves the others authenticating happily, and a secret created with a two-year expiry outlives the incident review by a wide margin. The rule is to enumerate every credential on every application object the compromised identities created or modified, and remove the ones you cannot account for. **API keys and personal access tokens.** SaaS platforms, source hosting and CI systems issue long-lived tokens tied to a user but independent of their password, and they are frequently scoped broadly. These are the quietest re-entry path because their use often looks like ordinary automation. **Cloud credentials.** Long-lived access keys are rotated or deleted outright. Temporary session credentials from an assumed role are different: they are self-contained until expiry and cannot be individually deleted, so you either wait out the session lifetime or attach a policy that denies actions for sessions issued before a chosen time, which is what the platform's revoke-sessions helper does under the covers. Also check for identities the adversary created rather than borrowed, and for trust-policy edits that let an external principal assume a role. **Registered authentication methods.** An authenticator or security key the adversary enrolled is both a way in and a way to own the recovery flow. Audit registered methods on every affected identity and re-enrol the genuine user through an out-of-band check. **Mailbox and collaboration persistence.** Forwarding rules, delegated mailbox access and sharing links keep delivering data with no authentication event at all. Remove them as part of revocation. **Federation.** The worst case is a stolen token-signing key or an added federation trust: the adversary mints assertions for any user, and no password reset anywhere in the estate touches it. Rotating signing material and reviewing trusted issuers belongs in the revocation plan whenever the compromise reached the identity infrastructure itself. ## Derive the list from the timeline, not from a template The generic checklist tells you which classes exist. It cannot tell you which objects in your tenant to act on. That comes from re-reading the identity audit trail across the entire dwell window, not just from the day the alert fired, filtering for credential-add, consent-granted, device-registered, trust-modified and role-assignment events, and for actor identities you already believe were held by the adversary. Every hit becomes a revocation item with an owner. If the dwell window is uncertain, widen it deliberately and say so, because an artefact created before your assumed start date is exactly the one that will still be there afterwards. ## Verifying, and what verification is worth Afterwards, watch authentication for the affected application objects and identities. Sustained absence of use is weak evidence, since a patient adversary simply waits, so pair it with a positive check that each enumerated credential is gone from the object, and keep a detection on first use of any credential you removed and on new credential-add events against those same objects. That is a much stronger position than declaring the reset complete. ## What a strong answer sounds like A strong answer names the classes rather than reciting one vendor's console, states plainly that these credentials are password-independent by design because automation needs them to be, and describes the enumerate-from-the-timeline method. A weak answer treats the mass reset as the containment and mentions only user-facing artefacts.