Who is accountable when mailbox permissions, tokens, and browser controls are not reviewed after an intrusion?

Why This Matters for Security Teams

Post-intrusion accountability is not just a governance question. It determines whether residual access is actually removed. When mailbox permissions, browser sessions, and tokens are left untouched, the original foothold may be gone but the attacker can still operate through trusted channels. That is why this question sits at the intersection of incident response, identity governance, and endpoint remediation, rather than belonging to one control owner alone. The control expectation is reinforced by NIST SP 800-53 Rev 5 Security and Privacy Controls, which ties identity, access, and system recovery to coordinated security outcomes.

In practice, the hardest failures occur when each team closes only its own ticket. Email administrators may remove a rule, identity teams may rotate a password, and endpoint teams may reimage a device, yet a delegated mailbox permission or refresh token remains valid. That creates a recovery gap that is easy to miss during a high-pressure incident. In practice, many security teams encounter the true scope of compromise only after the first cleanup appears complete, rather than through intentional validation of every residual access path.

How It Works in Practice

Accountability usually follows the control surface, but operational ownership should be explicit before an incident begins. Mailbox permissions are typically owned by email security or messaging administrators. Tokens and session revocation are usually owned by identity teams or the platform that issued the credential. Browser controls, cached sessions, and risky extensions often sit with endpoint engineering or endpoint security. Incident response owns coordination, evidence preservation, and closure criteria, but not every cleanup action itself.

A practical response should confirm three things in sequence: what access existed, what access was revoked, and what access could still be reconstituted. That means checking delegated mailbox access, forwarding rules, OAuth grants, application tokens, session cookies, and browser profile artifacts. Where non-human identities are involved, the question becomes broader, because service accounts, automation tokens, and API keys can continue to call systems long after a human account is reset. The OWASP Non-Human Identity Top 10 is useful here because it highlights how unmanaged secrets and over-permissioned machine identities can survive a standard user reset.

• Document which team owns each cleanup step before the incident starts.
• Revoke active sessions, refresh tokens, and application consents, not only passwords.
• Inspect mailbox delegation, forwarding, inbox rules, and shared mailbox access.
• Remove browser persistence, sync artifacts, and malicious extensions on affected endpoints.
• Verify the revocation on the system that issued the access, not only on the affected endpoint.

Effective recovery also depends on logging and validation. SIEM and identity logs should show whether a token was revoked, whether a mailbox rule was deleted, and whether a new session was created after remediation. If the investigation stops at endpoint reimaging, hidden persistence in cloud email or identity platforms can remain intact. These controls tend to break down when organisations use federated identity, multiple mail clients, and unmanaged browsers because the same account can retain access through several separate trust paths.

Common Variations and Edge Cases

Tighter cleanup often increases incident response time and operational overhead, requiring organisations to balance rapid restoration against full access validation. That tradeoff becomes more visible in hybrid environments, where mailbox services, single sign-on, and endpoint management are controlled by different teams. Best practice is evolving, but there is no universal standard for this yet on whether one function should own end-to-end post-intrusion access attestation or whether that should remain a shared responsibility model.

Edge cases matter. Shared mailboxes, service accounts, and automation tokens do not behave like ordinary user accounts, so a human-focused reset may leave machine access untouched. Browser controls are also inconsistent across managed and unmanaged devices, especially when sync, saved passwords, or cloud profile recovery is enabled. Where privileged access is involved, closure should include a fresh entitlement review, because mailbox delegation can effectively act as an indirect privilege escalation path. For identity-heavy environments, this is where NHI governance becomes relevant, since unattended tokens and secrets can outlive the incident that exposed them.

Security teams should also distinguish between removing access and proving removal. That distinction matters under NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where recovery, access review, and account management are part of formal evidence. If the environment uses browser-based access to cloud mail, federated tokens, or delegated admin rights, the last verified control should be recorded before closure. Otherwise, the incident may be declared contained while the attacker still has a working path back in.

Related resources from NHI Mgmt Group

• What breaks when a CLI prints or logs access tokens after browser sign-in?
• Who is accountable when an agentic browser changes data or permissions?
• Who is accountable when browser-based attacks bypass app login controls?
• Which identity controls should be reviewed after a major SaaS update?