30/09 edition: recovering an account does not close its sessions

What is the return-to-service decision?

This edition addresses incident owners, identity teams and application owners. The question is not merely whether login works again, but whether previous access has ceased to be useful and the new access was recovered through an approved route. It reports no incident on 30 September or internal Velqory intervention.

The final record and abstract of NIST SP 800-61 Rev. 3, published in April 2025, frame incident response within cybersecurity risk and CSF 2.0. Those metadata and abstract were read, not the PDF. This edition's detailed procedure is an original, untested proposal, not a NIST-certified runbook.

A protocol does not promise global logout

RFC 7009 concerns OAuth token revocation. In section 2.2, HTTP 200 can mean successful revocation or submission of an invalid token. Section 5 warns that, without access-token revocation support, revoking a refresh token does not immediately invalidate access tokens. A positive response must not become 'all access terminated'.

The text recognises implementation and propagation differences. Velqory recommends requesting each service owner's documentation on its own sessions, tokens and related grants. Do not assume that password reset, portal logout or token revocation has the same effect across applications.

Map before restoring access

Operational proposal: create one row per application and relevant access type, with an owner, available action and known limitation. Include browser sessions, application sessions, refresh tokens, access tokens and persistent grants where present. Do not record secret values in the dossier; use protected identifiers and timestamps.

The incident owner decides authorised containment and sequencing consistent with evidence preservation and continuity. An application whose semantics remain unconfirmed must stay explicitly open. Do not repeatedly try suspect credentials or use an attacker's account to manufacture closure evidence.

Acceptance by control domain

This is an untested proposal. Exercises must use authorised accounts and follow documentation. The verifier records the previous condition and subsequent observation without storing cookies or tokens in shared reports. No result is not the same as observed rejection.

The application is still open on another device

Hypothetical scenario: the identity portal confirms recovery action, but an application remains usable on a second device. The team should conclude neither that recovery failed in every service nor that the incident is over. It must locate the control domain retaining access and obtain its documented rule.

The exercise passes if it explains and treats that session within authorised scope, with subsequent observation and explicit limits. It fails if evidence is only a portal screen. If a residual window cannot immediately be removed, the incident owner must decide containment and return conditions, not erase the outstanding issue.

Do not rebuild the same weak route

CISA distinguishes phishing-resistant MFA from vulnerable alternatives and discusses migration obstacles. This does not prove a particular recovery process is secure. Velqory proposes reviewing the new authentication binding and recovery methods before normal use, with a responsible person and independent verification where possible.

Retain decisions, service-specific limitations and observations supporting return. Closing this work means accepting demonstrated scope, not asserting that every possible persistence mechanism was eliminated. The useful outcome is being able to explain what lost access, what was recovered and which signal requires reopening response.