We want standardization and consistency in many IT situations, but authentication calls for something more flexible. After all, not every user can use the same authentication factors and not every situation involves valuable resources that need more complex forms of authentication. To make authentication work for your organization, SMS and email may have business-critical roles but should come with risk-based and contextual analysis. It’s a way to avoid the one-size-fits-all approach that can cause inefficiencies, slow down access and even leave gaps in security. Ultimately, it’s about deciding what level of risk can be allowed, identifying the worst case scenario, and what actions should be implemented to reduce the risk.
It starts with identifying and avoiding a couple of common assumptions.
Assumption 1: A single standard authentication policy is the most secure
At first glance, a single, standard authentication policy sounds ideal – one policy to manage, one set of rules to secure, and less overhead for IT teams. Simple, right? Not quite. In reality, not every application holds the same level of sensitivity, and not every user interaction warrants the strongest authentication. A one-size-fits-all approach can lead to unnecessary friction – or worse, security blind spots. By adding context – like app sensitivity, user role, or location – you can apply stronger authentication only where it truly matters, striking the right balance between security and usability.
To support this contextual approach, start with a multi-layered strategy. The layers involved will vary based on elements such as risk profile and regulatory requirements. That means a similarly wide range of potential multi-factor authentication types that organizations can use, ranging from biometrics and hardware tokens to time-based one-time password (TOTP) apps and even SMS and email for less sensitive authentication flows.
Assumption 2: SMS and email aren’t suitable for authentication
Phones can be compromised, emails intercepted, session hijacking is on the rise, and phishing remains a constant threat. These are all valid concerns – but they don’t mean SMS and email should be dismissed entirely as authentication methods.
The reality is, not all users have access to – or are comfortable with – stronger authentication methods like hardware tokens or biometrics. This can include users with limited technical experience or third parties who don’t have the infrastructure to support advanced options. But nearly everyone has access to a phone or email.
That’s why SMS and email-based authentication still have a role to play – particularly in low-risk scenarios. Trying to enforce strong authentication universally can backfire. It increases friction, leads to user frustration, support tickets, and sometimes insecure workarounds.
The better approach? Contextual authentication – applying the right level of authentication based on the risk of the situation. It keeps identities secure and keeps experiences smooth.
How to mitigate risks with contextual authentication
Not every user has the same level of comfort or experience with authentication steps. Context-aware authentication that considers risk offers a powerful alternative to relying on people having strict password hygiene and avoiding password reuse, or expecting them to use factors that aren’t reasonable for whatever reason.
Risk-based authentication
Sometimes adding context is a simpler and faster alternative to investing in new infrastructure. That means seeking out solutions that can dynamically assess:
- IP reputation
- Geolocation
- Device parameters
This contextual information allows for a level of adaptive control over authentication that delivers login flexibility. When a user authenticates from a recognized device, in a typical location, and via a secure corporate network, it may be appropriate to relax authentication requirements – such as bypassing multi-factor prompts. In higher-risk situations, additional authentication steps may be required – or access may be blocked entirely. This could include scenarios where the user logs in from an unfamiliar location, a suspicious IP address or at an unusual time of day.
At the enterprise level, machine learning can be used to analyze patterns across thousands of users, building a behavioral profile that helps distinguish normal logins from risky ones. When login activity aligns with established norms, access can be granted seamlessly. As the system matures and baseline risk scores are refined, outliers and anomalies can automatically trigger step-up authentication or other security measures.
However, implementing this kind of adaptive intelligence takes time – budget approvals, planning, and technical deployment don’t happen overnight. In the meantime, organizations still need practical ways to balance security with usability. That’s where SMS and email-based authentication can still offer value in the right contexts.
SMS and email: Still viable authentication options (sometimes)
In low-risk scenarios, it can be reasonable for organizations to allow authentication via SMS or email. These methods offer a low barrier to entry, are cost-effective and work with tools nearly every user already has – like a phone or email account. Security can be further strengthened through user education, such as reminding users never to share one-time passcodes. On the admin side, additional safeguards like setting PINs with mobile carriers can help defend against SIM swap attacks and improve overall resilience.
For accounts with elevated privileges or access to sensitive applications, adaptive authentication often needs to be reinforced with stronger methods such as passwordless flows using biometrics or security keys.
CISA has already recommended moving away from SMS-based MFA for high-risk users, noting that it doesn’t qualify as strong authentication for individuals likely to be targeted. That concern isn’t theoretical – SIM-based attacks have remained prevalent, from a 400% surge in SIM swapping between 2018 and 2021, to reports in 2024 of bad actors offering telecom employees cash bribes to facilitate SIM swaps.
Still, despite these risks and federal guidance, SMS and email authentication can continue to serve a purpose – particularly in low-risk scenarios or as a fallback option – when implemented thoughtfully and supported with layered security measures.
Reducing risk with granular access control
Authentication can only go so far to mitigate risks. Organizations must also apply granular access controls to limit what can be accessed after authenticating. Examples include:
- Allowing read-only access to files
Minimize the risk of accidental or deliberate changes or deletions to sensitive information. - Restricting access to non-sensitive applications
Deploy an IAM solution that automatically assigns users to what they need, based on their attributes. - Increasing monitoring of access activity across the environment
Audit the current stack, to check for any shadow IT or areas where there’s limited visibility or knowledge of what exists and what needs to be protected. - Requiring step-up authentication for access
Apply dynamically, whenever there’s a required action that’s defined as higher risk.
There may be a single companywide portal or intranet. However, employees will still be accessing different applications and systems. Usually they’ll need different authentication factors, with different departments also aligning to different policies.
For example, DevOps want access to AWS. They need to login to the corporate network and gain access via a VPN, and require authentication. Whereas an HR worker requires access to communication platforms such as Teams or SharePoint. Two separate use cases, where it’s about context rather than being too rigid when securing and protecting company resources.
Apply user policies to groups, and then any user added can automatically follow the same policy, saving manual input and resources.
Example user policies to manage and secure resources
To further harden and add context to authentication, combine restrictive access policies with automated workflows. These can cover everything from password usage and hygiene to automated account suspensions and checking for the use of compromised credentials.
Login flows
For brute force defense, set limits for the number of times an incorrect password can be entered, and set how long a user is locked out. For more advanced and user-friendly security, use a passwordless solution combining ID and MFA, where only a username and authentication factor is required.
Granular SMS and email authentication usage
Map user directories and allow SMS or email authentication for low-risk accounts only, where there’s little possibility for lateral movement or sensitive data exfiltration. Enforce OTP for different user types, from admins only, through to all users. For critical systems and to ensure compliance with relevant laws, implement more advanced methods like adaptive passwordless authentication or traditional username and password combined with a physical security token.
Require trusted laptop and desktop devices
Add a trusted device certificate or PKI certificate to user devices and specify the length of validity. Naturally, this allows users a more seamless authentication experience with their usual (trusted) machine and through an IP allow list . But it may need MFA configured and also depends on the context and the level of regulation involved. Multi-factor is a requirement for PCI DSS, and MFA is also becoming mandatory for Azure and Google Cloud Platform throughout 2025.
Auto-suspend inactive users
Unless monitored, standing privileges can become a massive security threat. The FBI and CISA highlighted this attack vector in an advisory to critical infrastructure organizations, regarding Scattered Spider threat actors. To mitigate these vulnerabilities at enterprise scale, automatically suspend accounts if a user hasn’t logged in for 90 days. Apply this to sessions too, by setting how long a user can stay signed in for, from hours to minutes.
Password guidance
The most common password in the US is 123456. One quarter of US consumers say they’ve used other people’s streaming passwords. That’s a lot of easily guessed logins and widely shared passwords. That’s also why organizations that use password-based authentication must control how users manage their login credentials. One way is to define the combination of different character types required, from uppercase and lowercase, to numbers and special characters. Another is to specify user attributes that aren’t allowed, such as username, email address, or phone number. The best solutions verify and block the use of known compromised passwords.
Compromised credentials check
Credential stuffing is a common threat vector, driven by tools that make this trivial and the wide availability of stolen credentials on the dark web, including mass data dumps of up to 10 billion passwords. Implementing a credential check whenever a user creates an account or changes their password can reduce this risk. This feature can compare their chosen credentials against a live database of breached credentials, alerting when a match is found and blocking the use of that password.
Minimizing risk without compromising security
There’s always some level of risk when granting access or allowing authorized actions—but that risk can be better managed by applying context to authentication flows. That’s where methods like SMS and email still have a role to play.
By tailoring policies based on risk, IT leaders and administrators can restrict access when needed, while also reducing support overhead by implementing automation, rules and triggers to manage inactive or privileged accounts before they become vulnerabilities. At the same time, users can authenticate with simpler methods – like SMS or email – for low-risk resources, enabling smoother day-to-day operations. This more nuanced, flexible approach helps strike the right balance between security and usability, avoiding the pitfalls of a rigid, one-size-fits-all strategy.
