Multi-factor authentication for your corporate online services
Page 6 of 7
Avoiding MFA anti-patterns
The term 'anti-pattern' is used to refer to any repeated (but ineffective) solution to a common problem. While any MFA deployment is better than using passwords alone to authenticate, some MFA deployments ultimately leave organisations less protected than they had assumed. You should ensure that none of the following anti-patterns apply to your existing or planned MFA implementation.
1. Bypass by legacy protocols
Some online services that support strong MFA also support authenticating via legacy and weaker protocols that do not support MFA. This can mean that only a password is required to get access using these protocols, even if a user account has the strongest MFA methods enforced on it everywhere else. Common culprits are often enabled for compatibility reasons, such as legacy email, file transfer, and remote management interfaces.
You should confirm that these legacy protocols are disabled when using online services, and replaced by modern alternatives that support the requirement for a stronger MFA method.
2. Backdoor by excluded accounts
Some accounts are excluded from strong MFA because individual users declare that it’s ‘too much of a nuisance’. Inevitably, such individuals are often ones that also have access to the most sensitive data due to their role and responsibilities. Additionally, some legacy IT systems misuse user accounts to enable automation of services, such as access to an inbox or calendar.
All user accounts with access to sensitive data should have MFA enforced (with the exception of heavily monitored emergency 'break glass' accounts if you choose to do so). Systems that require access to other systems or services should use an access method that minimises access permissions, and uses modern service authentication methods, such as certificate-based credentials.
3. Time-based re-authentication
A common misconception is that there is an overall security benefit to authentication sessions being rigidly ‘timed out’ after a short period (often a pre-defined number of hours). Forcing periodic re-authentication limits the time that a session credential (often a ‘cookie’ or other ‘token’) is useful for, in case it is stolen by malware. However, this also weakens authentication in online services in two more significant ways:
- Forcing a user to periodically re-authenticate does not consider active changes in the service’s trust in their identity, or the device they are using. Neither does it effectively limit an attacker’s impact, as they often use a stolen session credential to promptly find and steal sensitive data before they are detected. This also often delays how quickly an attacker’s access can be cut off after they are detected, as the online service only re-checks a user’s access once the pre-defined period has elapsed.
- Forcing a user to frequently re-authenticate will desensitise them to entering their credentials. This makes users more susceptible to common phishing attacks.
Some online services, such as Microsoft 365 and Google Workspace, have an enabled-by-default security heuristic that attempts to identify the re-use of a stolen session credential. Detection of a suspected stolen session credential should trigger a contextual access policy to block its use and raise the risk of the affected user’s account(s) and device(s). It should also block further access until the appropriate security response has remediated the risk back to an acceptable level.
You should only require your users to re-authenticate when there is a need to regain assurance. For example, when performing a high-risk action or when re-building trust in a user’s digital identity (after a suspected breach of their account and/or device).