Session revocation after password reset is the containment step that decides whether a stolen account is actually closed or merely given a new front-door key. On September 29, 2026, France's national cybersecurity agency, ANSSI, published its incident report on attacks against the French tax administration. The report shows that one attack session remained usable after responders reset a compromised password, allowing data extraction to continue for nearly 16 more hours.
The lesson is immediate for every organization, not only government agencies. A password reset can stop a new login with an old password. It does not automatically invalidate every browser cookie, refresh token, application session, API token, or federated session already issued to the attacker.
Key Takeaway: Treat password reset and session revocation as separate controls that must execute together during account-compromise response.
What the French tax breach revealed
ANSSI's September 29 public report reconstructs malicious activity affecting the Direction générale des Finances publiques, or DGFiP, between May and August 2026. Investigators identified two areas of data exfiltration, including information associated with individuals and businesses.
The attackers did not need a novel exploit to enter the main staff-facing systems. ANSSI says they obtained and used legitimate employee credentials after those credentials had been used on personal devices. Sensitive portals lacked strong authentication, which allowed stolen passwords to become valid access.
The full ANSSI incident report describes a particularly important containment failure. After suspicious activity was identified, a password was reset, but an existing session on another portal remained active. The attacker continued extracting data for almost another 16 hours.
The broader campaign also exposed a monitoring gap. ANSSI says neither the DGFiP's supervision nor ANSSI's own sensors detected the two exfiltration waves. One portal used by the attacker was not being monitored, and the available signals were not correlated across systems.
Key Stat: One password reset left a valid attacker session running long enough for nearly 16 additional hours of activity.
Why password resets do not always end access
A password proves identity at the moment an application authenticates a user. After successful authentication, most applications issue a session identifier or token so the user does not have to enter a password for every request.
That token temporarily becomes the user's proof of access. OWASP's session management guidance explains that a session identifier can be equivalent to the strongest authentication method used to create it. If an attacker already holds a valid token, changing the password may not affect that token unless the application or identity platform explicitly invalidates it.
Several layers can keep access alive:
- a browser session cookie issued by the business application
- an identity-provider session used for single sign-on
- an OAuth access token with time remaining
- a refresh token that can obtain new access tokens
- a mobile or desktop app session cached on a device
- an API key, app password, or personal access token created after compromise
These layers may be controlled by different systems. Resetting a directory password might invalidate some identity-provider sessions while leaving application-managed cookies untouched. Revoking identity-provider refresh tokens may still not terminate a session that a downstream application manages locally.
Microsoft's emergency access-revocation guidance makes that boundary explicit: Microsoft Entra ID cannot directly revoke a session token issued and controlled by another application. Responders need to know which system created each token and which control can terminate it.
Common Mistake: Assuming that “reset password” means “sign out everywhere.” Verify the actual behavior for every critical identity provider and business application.
Session revocation after password reset needs a full map
An effective response starts with an identity and session map, not a generic checklist. You need to know how an employee reaches sensitive data, which system authenticates them, and which component maintains the resulting session.
For each critical application, document:
- Authentication source. Is access based on a local password, Active Directory, cloud identity, social login, certificate, or another provider?
- Session owner. Does the identity provider manage the active session, or does the application issue its own cookie?
- Token types. Which access tokens, refresh tokens, device tokens, API keys, and app passwords can exist?
- Revocation control. Can an analyst terminate one session, all sessions for one user, or every session in an emergency?
- Propagation delay. How long can a revoked token continue to work because of caching, offline validation, or application design?
- Evidence source. Which logs prove that revocation was requested and that access actually stopped?
Do not wait for an incident to answer these questions. Test them with a controlled account. Sign in from two browsers, reset the password, revoke sessions, and confirm when each browser loses access. Repeat the test for mobile apps, thick clients, VPNs, and high-value SaaS tools.
This complements a broader account recovery security plan. Recovery controls protect the path back into an account, while session revocation removes access that has already been granted.
Build a complete account-compromise containment action
Responders should be able to launch a coordinated containment action from one playbook or automation. A password reset is only one part of that action.
1. Block new authentication
Temporarily disable the account or block sign-in when business impact permits. This creates a stable window for investigation and prevents the attacker from immediately authenticating again with another stolen factor.
Reset the password to a random value that neither the attacker nor the user knows. Do not send the replacement password through the same email account or device that may be compromised.
2. Revoke active sessions and tokens
Terminate identity-provider sessions, refresh tokens, remembered devices, application sessions, VPN sessions, and relevant mobile sessions. If a critical application maintains its own cookies, use its administrative controls or backend revocation mechanism as well.
The current OWASP Application Security Verification Standard says administrators should be able to terminate active sessions for an individual user or all users. It also calls for a way to terminate other active sessions after a password or authentication-factor change.
For self-contained tokens, plan for revocation before the incident. Options include a deny list, a per-user “valid after” timestamp, shorter token lifetimes, or per-user signing-key rotation. A stateless token without a revocation path is an operational constraint that responders must understand.
3. Remove durable persistence
An attacker may create another way back in before containment begins. Review and remove:
- newly enrolled MFA methods or recovery addresses
- inbox forwarding rules and delegated mailbox access
- OAuth grants and connected applications
- API keys, personal access tokens, and app passwords
- new devices, certificates, SSH keys, or passkeys
- scheduled exports, service accounts, and automation credentials
This is why the employee offboarding security checklist treats access removal as a system-wide task. A compromised identity and a departing employee create different incidents, but both expose the same dependency problem: access is distributed across more systems than the primary directory.
4. Re-establish trusted access
Only restore access after the endpoint, authentication factors, and recovery channels are trustworthy. Re-register MFA from a managed device, issue a new password through a verified channel, and require fresh authentication.
For privileged users, consider issuing a clean device or moving them to a known-good administrative workstation. If credentials were used on an unmanaged personal device, resetting them before addressing that device can simply expose the replacement credentials again.
Pro Tip: Build one analyst action that blocks sign-in, resets the password, revokes sessions, and opens the persistence review. Separate manual steps are easy to miss under pressure.
Detection must follow the business application
The French incident shows why perimeter visibility is insufficient when attackers use valid accounts. A login may look ordinary while the data-access pattern is clearly abnormal.
Collect application-level telemetry for systems that hold sensitive or high-volume data. Useful signals include:
- access outside the user's normal hours or geography
- a sudden increase in records viewed, searched, or exported
- repeated page-by-page requests consistent with automated scraping
- multiple active sessions from unrelated devices or networks
- continued requests after password reset or account containment
- access to unfamiliar departments, tenants, or data categories
- unusual API use by an account that normally uses a browser
Correlate those signals with identity, endpoint, VPN, email, and data-loss prevention logs. A suspicious sign-in in one system and an unusual export in another may be weak alerts alone. Together, they can describe the attack path.
Set volume thresholds around the data, not only the network. A business application should know when a normal staff account begins retrieving thousands of records. Rate limits, export approvals, and per-user quotas can reduce damage even when an attacker holds valid credentials.
The same principle appears in the shared account security guide: attribution and containment break down when multiple people or processes share one identity. Named accounts, scoped roles, and application logging make it possible to see which session did what.
Test the control before you need it
Run a short tabletop and technical exercise around a compromised employee account. The scenario should assume the attacker already has a valid browser session and has added at least one persistence method.
Measure the response in four stages:
- Decision time: How quickly does the analyst identify the affected identity and applications?
- Execution time: How quickly are sign-in, sessions, tokens, and persistence contained?
- Effective time: When do test sessions actually stop reaching protected data?
- Verification time: When can the team prove the attacker no longer has access?
Include one application that uses local sessions and one that relies entirely on the central identity provider. The difference will reveal whether the playbook is based on real application behavior or assumptions.
Track gaps as engineering work. If an application cannot revoke one user's sessions, add that limitation to the risk register, shorten token lifetimes, restrict data access, or place the application behind a control that can enforce reauthentication.
The action to take today
ANSSI published the French tax incident report on September 29, 2026, making this a current containment lesson backed by a detailed public investigation. Review your account-compromise playbook and find every place where “reset password” appears without “revoke all sessions and tokens.”
Then test the sequence. Confirm that identity-provider sessions, application cookies, refresh tokens, VPN sessions, mobile clients, and persistent grants stop working when the account is contained. Add monitoring for activity that continues after the containment timestamp.
A password reset changes a secret. Session revocation after password reset ends previously granted access. Incident response needs both, followed by evidence that the attacker is actually gone.