How should security teams contain an account compromise when a phishing kit can enroll a new passkey during an active session?

Treat the incident as persistence, not just session theft. Revoke active sessions, reset the password, and then check for newly enrolled passkeys, security keys, OAuth grants, mailbox rules, recovery changes, and delegated access. If an attacker added a new authenticator, password resets alone will not remove it. Restoration should happen only after unauthorized authentication methods are removed and the account is fully reviewed.

Why This Matters for Security Teams

A phishing kit that can enroll a new passkey during an active session turns a simple login compromise into durable account persistence. The attacker is no longer relying on a stolen cookie alone; they are modifying the victim’s authentication posture and can survive password changes unless the new authenticator is removed. That is why incident response has to treat the event as identity takeover plus recovery tampering, not just session theft. Guidance on account abuse in The 52 NHI breaches Report shows how often control gaps become visible only after an attacker has already established durable access.

For security teams, the practical risk is that modern identity systems often trust the most recently enrolled factor too much, especially when enrollment happens inside an authenticated browser context. A user’s existing session can become the bridge that lets an attacker add a new factor, update recovery paths, and then lock defenders out. NIST’s Security and Privacy Controls emphasize account lifecycle controls, but the operational problem is that many identity stacks still assume enrollment events are benign unless explicitly reviewed. In practice, many security teams discover this persistence only after the attacker has already used the account to reset adjacent systems or access downstream services.

How It Works in Practice

Containment should start with revoking all active sessions and invalidating refresh tokens, then resetting the password only as one step in a broader recovery sequence. If the identity provider supports it, security teams should immediately review and remove newly enrolled passkeys, security keys, authenticator apps, recovery codes, delegated access, mailbox rules, OAuth grants, and any changes to trusted devices or recovery contact methods. The key principle is to close every path the attacker may have added while the session was live. NHIMG’s analysis in CoPhish OAuth Token Theft via Copilot Studio is a useful reminder that identity abuse often extends beyond the initial credential theft.

• Revoke current sessions before the attacker can pivot or reauthenticate.
• Reset the password and invalidate all remembered device trust.
• Enumerate newly added passkeys, security keys, and MFA methods.
• Inspect mailbox forwarding, OAuth consent, and delegated admin access.
• Check recovery email, phone, and helpdesk-assisted reset changes.
• Force step-up verification before restoring account use.

This workflow aligns with the logic of short-lived compromise handling: remove persistence first, then restore trust. It also fits the warning from Ultimate Guide to NHIs — Why NHI Security Matters Now that identity compromise rarely stays isolated once an attacker can reuse trusted access paths. Where available, pair manual review with identity logs that show factor enrollment, session revocation, consent grants, and recovery changes in a single timeline. These controls tend to break down in federated environments with weak audit logs and delayed synchronization, because the attacker may add a new factor in one system while defenders are reviewing stale state in another.

Common Variations and Edge Cases

Tighter account recovery control often increases support friction, requiring organisations to balance fast user restoration against the risk of reintroducing an attacker’s access path. That tradeoff is especially visible when executives, admins, or customer-facing identities need rapid recovery. Current guidance suggests the safest approach is to delay restoration until unauthorized authenticators and linked channels are confirmed removed, but there is no universal standard for how much evidence is enough across every identity platform.

Edge cases matter. In passwordless environments, a passkey may be the primary authenticator rather than a second factor, so removal of the enrolled key is the decisive containment step. In environments with SSO and downstream SaaS, one compromised identity can also carry persistent OAuth tokens that outlive the primary session, so token revocation must be part of the response. In high-risk cases, security teams should consider device revalidation, mailbox quarantine, and admin approval for any factor re-enrollment. The recent LLMjacking: How Attackers Hijack AI Using Compromised NHIs research is relevant here because it shows how quickly attackers operationalize stolen access once they have it.

Best practice is evolving toward strong enrollment protections, alerting on factor changes, and separate approval workflows for privileged accounts. Until those controls are mature, any response plan that stops at password reset is incomplete.

Related resources from NHI Mgmt Group

• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?