You've implemented MFA. Your users authenticate at login. The session token is valid for eight hours. That's the pattern most organizations follow, and it satisfies the authentication requirements in ISO/IEC 27001 Annex A.5.17 and the SOC 2 CC6.1 control criteria.
But here's the question: what happens when the risk profile of that authenticated session changes two hours in?
The Question at Hand
The debate isn't whether MFA matters (it does). It's whether a single authentication decision at login provides enough assurance for the entire session, or whether you need continuous risk evaluation to detect when a previously trusted session becomes suspect.
This is important for compliance. Both frameworks require you to manage access based on risk. ISO/IEC 27001 Clause 6.1.2 requires organizations to evaluate information security risks. SOC 2's CC3.2 criteria expect you to identify and assess changes affecting your system of internal control. If your authentication strategy can't adapt to changing session risk, you're meeting the letter of the requirement but missing the intent.
The Case for Login-Only Authentication
The argument for keeping authentication at the login boundary is straightforward: you're trading some theoretical risk for operational simplicity.
Users authenticate once with something they know and something they have. You validate their identity, issue a session token, and that token remains valid until expiration or explicit logout. This model has worked for years because it's predictable. Your developers know how to implement it. Your users understand it. Your auditors can verify it.
From a controls perspective, you can point to specific implementations. You've configured MFA across all privileged accounts. Your session timeout policy aligns with the sensitivity of the data (15 minutes for administrative access, two hours for standard users, eight hours for read-only). You log every authentication event. You monitor for impossible travel (a user can't authenticate from New York and Tokyo within the same hour).
This approach also respects user experience in ways that matter for productivity. A financial analyst running a complex report shouldn't have to re-authenticate halfway through because they accessed a dataset they don't normally touch. A support engineer troubleshooting an urgent issue shouldn't face an MFA prompt every time they pivot to a different system.
You're already asking users to manage hardware tokens or authenticator apps. Adding mid-session challenges risks authentication fatigue, where users start looking for workarounds or complaining that security is blocking their work.
The Case for Continuous Authentication
The counterargument is that attackers have adapted faster than your authentication model has.
They're no longer just stealing passwords. They're stealing session tokens after MFA succeeds. They're using residential proxies and commercial VPNs to make compromised sessions look like legitimate traffic from expected locations. When an attacker routes their connection through residential proxy infrastructure, your IP geolocation check shows the user connecting from their home city, exactly as expected.
This isn't theoretical. Attackers have access to infrastructure that disguises malicious activity as normal user behavior. A compromised session that passed MFA at 9 AM might be under attacker control by 11 AM, and your login-only authentication model has no mechanism to detect that shift.
Continuous authentication argues that you should evaluate risk throughout the session, not just at the entry point. You collect passive signals: device fingerprint consistency, typing patterns, mouse movement, network characteristics, access patterns. You build a baseline of normal behavior for each user. When the session deviates from that baseline (unfamiliar device suddenly appears mid-session, user accesses data outside their normal scope, behavioral patterns change), you have options beyond "allow" or "deny."
You can require step-up authentication for sensitive actions. If a user who normally reviews customer records suddenly attempts to export the entire database, that's the moment to ask for re-authentication. If someone connects through an anonymizing service they've never used before and immediately starts modifying account settings, you can challenge that activity without blocking their entire session.
This approach aligns with ISO/IEC 27001's risk-based thinking. Clause 8.1 requires you to implement operational planning and control that addresses assessed risks. A static authentication decision made at login doesn't account for risks that emerge during the session.
Where Practitioners Actually Land
In practice, most security teams are implementing a hybrid model without calling it that.
You're not asking users to re-authenticate every ten minutes. You're identifying specific actions that warrant additional verification: changing email addresses, modifying security settings, accessing financial data, downloading bulk records. Those actions trigger step-up authentication regardless of how recently the user logged in.
You're also using passive signals to build confidence or raise alerts. If the device fingerprint changes mid-session, that's worth investigating. If a user suddenly starts accessing resources from an IP address with anonymizing infrastructure characteristics they've never used before, your security team gets an alert even if you don't immediately interrupt the user.
The implementation challenge is determining which signals matter for your environment. Location history works well if your users don't frequently travel. It's less useful if you support a remote workforce that regularly connects from different countries. Device consistency is valuable until someone's laptop dies and they need to work from a loaner.
You need enough context to distinguish unusual-but-legitimate from actually-suspicious. An employee connecting through an unfamiliar residential proxy might just be working from a coffee shop. That same employee connecting through that proxy and immediately requesting data they've never accessed before is a different risk profile.
Our Take
Authentication shouldn't end after MFA succeeds, but it also shouldn't become a constant interruption.
The right approach is risk-adaptive. You authenticate at login. You monitor session behavior against established baselines. You require step-up authentication for high-risk actions, regardless of session age. You investigate anomalies that combine multiple unusual signals (new device plus anonymizing infrastructure plus out-of-scope data access).
This satisfies both the technical requirement and the practical constraint. You're continuously evaluating risk (ISO/IEC 27001 Clause 6.1.2, SOC 2 CC3.1) without degrading user experience to the point where people start looking for workarounds.
The tradeoff is complexity. You need to define what constitutes high-risk actions for your environment. You need to tune your behavioral baselines so they catch actual threats without generating false positives every time someone works from a new location. You need monitoring infrastructure that can evaluate session context in real time.
But the alternative is hoping that a trust decision you made at 9 AM remains valid at 5 PM, even though the threat landscape and session context have both changed. That's not a risk posture most organizations can defend when an auditor asks how you're addressing adaptive threats.
MFA remains essential. Continuous risk evaluation makes it effective.
