Identity is the new perimeter, but session tokens are the unlocked side door
Modern security teams protect MFA and SSO, but attackers increasingly chase cookies, OAuth grants, refresh tokens, device codes, and SaaS sessions.

Key takeaways
- MFA reduces password risk, but stolen sessions and OAuth grants can bypass the normal login ceremony.
- Identity incidents should include token revocation, app grant review, device trust checks, mailbox rules, and SaaS audit log review.
- The best controls combine phishing-resistant MFA, conditional access, short session lifetimes for risky contexts, device posture, and anomaly detection.
- SaaS identity response needs rehearsed playbooks because every platform has different revocation behavior.
Research integrity
Sources
- https://www.cisa.gov/resources-tools/resources/secure-by-design
- https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
- https://owasp.org/www-project-top-10-for-large-language-model-applications/
- https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins
Identity is the new perimeter, but session tokens are the unlocked side door
Security teams spent years teaching users not to reuse passwords, then spent more years rolling out MFA. That work mattered. It made simple credential stuffing harder and pushed many attackers away from password-only attacks. But the perimeter moved again. In 2026, identity defense is less about the login screen and more about what happens after the login succeeds.
The side door is the session. A browser cookie, refresh token, OAuth grant, device registration, API token, or trusted SaaS session can carry more practical value than a password. If an attacker gets the session, the victim may not see a fresh MFA prompt. The system may believe the ceremony already happened.
This is why identity incidents feel strange to teams raised on endpoint malware. There may be no suspicious executable. No beacon. No obvious persistence on disk. The attacker signs in, consents to an app, creates an inbox rule, exports data, adds a forwarding address, registers a device, generates a token, or quietly searches documents. The crime scene is distributed across audit logs.
MFA is still necessary. The lesson is not that MFA failed. The lesson is that MFA is one control in a chain. Adversary-in-the-middle phishing can relay a login and capture a session. Infostealer malware can lift browser cookies. OAuth phishing can convince a user to grant a malicious app access that survives password resets. Device-code phishing can abuse flows designed for constrained devices. A compromised laptop can turn a trusted device into a trusted problem.
Good identity defense starts with phishing-resistant MFA for the accounts that matter most: administrators, developers, finance, executives, help desk, cloud operators, and anyone with broad data access. Passkeys and FIDO2 security keys reduce the chance that a user can be tricked into authenticating to a fake site because the authenticator is bound to the real origin. This is not perfect security, but it changes the attacker's economics.
Conditional access is the second layer. Location, device health, impossible travel, unfamiliar sign-in properties, risky IPs, token replay signals, and privilege level should influence the session. A payroll administrator signing in from a managed laptop in the usual country is one thing. The same account accessing export tools from a fresh browser on a residential proxy is another.
Session lifetime is a design choice, not a default to inherit blindly. Long sessions reduce user friction, but they also increase the value of stolen tokens. High-risk apps, privileged roles, unmanaged devices, and unusual contexts deserve stricter refresh behavior. The goal is not to force everyone to log in every hour. The goal is to make stolen sessions decay before they become durable access.
OAuth grants need regular housekeeping. Many organizations can name their identity provider but cannot name the third-party apps with delegated access to mail, files, calendars, chat, CRM, or source code. Attackers know this. A malicious or compromised app can become quiet persistence. Security teams should review consent policies, restrict user consent for sensitive scopes, require admin approval where appropriate, and alert on suspicious grants.
Detection should look for behavior, not just failed logins. New inbox rules, mass downloads, unusual search activity, impossible travel, new device registrations, privilege elevation, MFA method changes, forwarding setup, suspicious OAuth consent, token use from unusual networks, and admin portal access from fresh sessions all deserve attention. Identity logs are production security telemetry. Treat them like endpoint and network logs.
Response playbooks must be platform-specific. 'Reset the password' is not enough. The team may need to revoke sessions, invalidate refresh tokens, remove OAuth grants, disable app passwords, rotate API keys, remove trusted devices, review mailbox rules, inspect SaaS audit logs, check cloud access, and notify affected data owners. Each platform has different words for the same concepts. Practice before the incident.
The human side matters too. Users should be trained to report weird consent prompts, unexpected device-code requests, repeated MFA prompts, and browser warnings. Help desk teams should verify identity carefully before resetting MFA. Executives should understand that identity security is not a login project; it is an access lifecycle.
Identity became the perimeter because work moved into SaaS, cloud consoles, APIs, and remote devices. That perimeter is real, but it has more doors than people think. Passwords are one. Sessions are another. OAuth grants are another. Trusted devices are another. The best security teams protect the whole hallway, not just the front desk.
Frequently asked questions
Can attackers bypass MFA?
They can sometimes bypass the need to perform MFA again by stealing active sessions, abusing OAuth grants, using adversary-in-the-middle phishing, or compromising trusted devices.
What should teams revoke after identity compromise?
Revoke active sessions, refresh tokens, suspicious OAuth app grants, app passwords, API keys, and trusted device registrations where appropriate.
What is phishing-resistant MFA?
Phishing-resistant MFA uses cryptographic authenticators such as passkeys or FIDO2 security keys that are bound to the legitimate site and resist credential relay attacks.



