AWS Security and Compliance: Detecting Misconfigurations and Responding to Cloud Incidents
Detect AWS misconfigurations and incidents with monitoring, Security Hub, CloudTrail, GuardDuty, and response.
If identity is the foundation of zero trust, multi-factor authentication is what keeps that foundation from cracking under pressure. A password by itself is just one piece of proof, and it is the piece attackers are best at stealing, guessing, or buying from the dark web.
MFA adds a second factor, something the user has or is, so a stolen password alone is not enough to get in.
The impact of this is hard to overstate. The Microsoft Security blog on MFA effectiveness has reported that enabling MFA blocks the vast majority of automated account compromise attempts, even when attackers already have a valid password in hand. That single statistic explains why MFA is treated as a baseline requirement in nearly every zero trust framework, not an optional add-on.
It is also worth understanding why passwords fail so consistently in the first place. People reuse them across multiple accounts, choose ones that are easy to guess and often fall for phishing pages designed to look identical to legitimate login screens.
None of these weaknesses can be fully solved through policy alone, such as requiring longer passwords or more frequent resets. MFA works because it does not try to fix the password problem directly. It simply makes a stolen password far less useful on its own.
MFA is only one layer of a stronger access control strategy, so for the full framework, read Zero Trust Architecture for Cloud Environments: The Complete Guide for Modern Organizations.

MFA works by combining different categories of proof.
Something the user knows, such as a password or PIN.
Something the user has, such as a phone, hardware token, or authenticator app.
Something the user is, such as a fingerprint or face scan.
A strong MFA setup combines at least two of these categories, since stealing a password and physically stealing someone’s phone at the same time is far harder than stealing a password alone.
Not all second factors offer the same level of protection. SMS-based codes are better than nothing, but they are vulnerable to SIM swapping attacks, where an attacker tricks a carrier into transferring a victim’s phone number to a new device.
The CISA guidance on phishing-resistant MFA recommends moving towards stronger methods like authenticator apps or hardware security keys wherever possible, especially for accounts with elevated privileges.
It helps to think of these factor types as a rough hierarchy rather than interchangeable options. SMS codes sit at the lower end, useful but not bulletproof. Authenticator apps offer a meaningful step up, since they are not tied to a phone number that can be hijacked.
Hardware security keys and biometric methods sit at the top, since they are extremely difficult to intercept or replicate remotely, even by a determined attacker.

The most common mistake is not skipping MFA entirely. It is applying it inconsistently.
Email and primary logins get protected, but internal admin panels, legacy systems, or third-party tools often slip through the cracks. Attackers do not need to break through the strongest door in the building. They just need to find the one that was left unlocked.
Another frequent issue is MFA fatigue, where users are bombarded with so many approval prompts that they start approving requests without really checking them, sometimes even ones they did not initiate.
This pattern has been used successfully in real breaches, where attackers simply spam push notifications until a tired employee taps approve by mistake.
A third, quieter mistake is failing to plan for account recovery. If MFA is enforced everywhere but there is no secure backup process for a lost phone or hardware key, employees end up locked out.
The workaround that IT teams create under pressure is sometimes weaker than the original MFA setup it was meant to support.
Knowing MFA matters is the easy part. Rolling it out in a way that holds up under real-world use, without frustrating employees into finding workarounds, takes more care.

Start with the accounts that would cause the most damage if compromised: administrators, finance systems and anything with access to sensitive customer data.
These deserve the strongest available factors, such as hardware keys or authenticator apps, rather than SMS codes. Lower-risk systems can follow once the highest-value targets are covered.

For privileged accounts especially, it is worth moving beyond basic push notifications towards methods that cannot be approved blindly.
Number matching prompts, where users must enter a code shown on their screen rather than just tapping yes, help reduce MFA fatigue attacks significantly.
The FIDO Alliance’s overview of passwordless and phishing-resistant authentication covers how hardware-backed methods like passkeys are becoming the gold standard for high-security environments.
Older applications sometimes do not support modern MFA out of the box. Rather than leaving them exposed, many organisations place these systems behind a modern identity gateway or VPN that enforces MFA before traffic ever reaches the legacy application.
It is an extra step, but it closes a gap attackers actively look for.
This is often the part of an MFA rollout that takes the longest, since legacy systems were not built with modern authentication in mind.
Budgeting extra time for this phase, rather than treating it as a quick afterthought, tends to prevent legacy systems from becoming the weak link in an otherwise strong rollout.
A surprise MFA rollout tends to generate confusion and help desk tickets. Giving employees advance notice, simple setup instructions and a short grace period before strict enforcement makes adoption smoother and reduces resistance.
Framing it as protecting their own accounts, not just company data, also tends to improve buy-in.
MFA is not something to configure once and forget. New phishing techniques emerge, and methods that felt secure a few years ago, such as basic SMS codes, are weaker today than they once were.
Periodically reviewing which factors are in use, and upgrading weaker ones, keeps protection aligned with current threats.
Strong MFA, applied consistently and paired with phishing-resistant methods for critical accounts, closes one of the most commonly exploited gaps in cloud security.
It is a relatively small operational lift for a significant reduction in risk, and it remains one of the highest-impact security investments an organisation can make at any stage of its zero trust journey.
If you want a clear framework for rolling out MFA alongside the rest of your identity and access strategy, our Zero Trust Architecture for Cloud Environments course walks through prioritisation, tooling and real rollout sequencing.
Explore the Course → Zero Trust Architecture for Cloud Environments