The attack happened at 3:17 AM on a Tuesday. A healthcare startup’s AWS root account fell to a sophisticated phishing campaign that bypassed their SMS-based MFA. Within hours, attackers had spun up cryptocurrency mining instances across multiple regions and exfiltrated patient data from their RDS databases.
This scenario plays out more often than AWS customers want to admit. But here’s what’s different in 2025: it’s entirely preventable with the security tools AWS has rolled out over the past year.
While many organizations are still catching up with basic MFA requirements, AWS has been quietly revolutionizing how we think about cloud security. From making root account MFA mandatory to expanding Verified Access beyond HTTP protocols, these aren’t just incremental updates—they’re fundamental shifts that determine whether your organization becomes a security leader or another breach statistic.
Why AWS Security Had to Evolve (And Why You Can’t Wait)
Traditional cloud security assumed a perimeter you could defend. VPNs created trusted tunnels. Passwords plus SMS tokens felt adequate. Bastion hosts provided controlled access points.
That model shattered against the reality of sophisticated attacks, distributed workforces, and cloud-native architectures that span multiple regions and services.
AWS’s response has been decisive. In May 2024, they began requiring MFA for root users across AWS Organizations. By June, they introduced passkey support for both root and IAM users. February 2025 brought Verified Access support for non-HTTP protocols, effectively enabling VPN-less access to your most critical infrastructure.
These changes aren’t recommendations—they’re the new baseline for organizations that want to avoid becoming headlines.
Passkeys Meet AWS: When Cryptography Replaces Hope
The Traditional Problem: Your root account credentials represent the keys to your entire AWS kingdom. Yet most organizations protect them with passwords and SMS tokens that can be phished, SIM-swapped, or socially engineered.
AWS’s Solution: FIDO2-based passkeys that provide cryptographic, phishing-resistant authentication using your device’s built-in biometric capabilities or synced credential managers.
Here’s what changed and why it matters:
What AWS Actually Did
In June 2024, AWS added passkey support as an MFA method for both root and IAM users. This isn’t just another authentication option—it’s a fundamental shift toward cryptographic proof of identity rather than shared secrets that can be compromised.
Passkeys work by generating unique cryptographic key pairs for each service. Your device holds the private key (secured by biometrics), while AWS stores the public key. When you authenticate, you’re proving you possess the private key without ever transmitting it.
Current Reach: Available in all AWS regions except China. MFA for root users is now mandatory, with grace periods and notifications for compliance.
Why This Changes Everything
Traditional MFA relies on “something you know” (password) plus “something you have” (phone). But both can be stolen or intercepted. Passkeys eliminate the “something you know” entirely, replacing it with “something you are” (biometric) plus cryptographic proof.
The phishing protection is particularly crucial. Even if attackers create perfect replicas of AWS login pages, passkeys won’t work on fake sites because the cryptographic challenge includes the actual domain.
What You Need to Do Right Now
Step 1: Audit Your Current Exposure – Identify all root accounts across your AWS Organizations – Document which critical IAM users lack MFA or use SMS-based tokens – Map out member accounts that still have active root passwords
Step 2: Enable Passkey MFA – Access the IAM console → “Assign MFA device” → choose “Passkey” – Test the passkey authentication flow with backup methods configured – For organizations: enable centralized root access management
Step 3: Eliminate Legacy Risks – Disable passwords and root access keys for member accounts – Remove SMS-based MFA in favor of passkeys where possible – Document your new authentication requirements for incident response
The math is simple: every day you delay implementing passkeys is another day your organization remains vulnerable to phishing attacks that have already compromised similar companies.
Verified Access: The Death of VPNs and Bastion Hosts
The Legacy Problem: Your developers need SSH access to production EC2 instances. Your DBAs need direct connections to RDS clusters. Your ops team needs RDP access to Windows servers. Traditional solutions involved VPNs (creating broad network access) or bastion hosts (single points of failure with complex key management).
AWS’s Revolution: Verified Access now supports non-HTTP protocols, enabling zero-trust, identity-based access to SSH, RDP, JDBC/ODBC, and RDS connections without VPNs or bastions.
What Just Became Possible
AWS Verified Access launched in preview in late 2022, focusing on HTTP/HTTPS application access. The February 2025 general availability of non-HTTP support fundamentally changes how you can secure infrastructure access.
Instead of granting broad network access through VPNs, you can now enforce granular, identity-based policies for specific resources. Each access decision considers user identity, device posture, location, and risk factors in real-time.
Example Architecture: A developer requests SSH access to a production database server. Verified Access checks their identity (via your IdP), validates their device compliance (via endpoint management), confirms the request matches approved access patterns, and creates a secure tunnel for that specific session only.
The Economic Reality
VPN infrastructure costs include licensing, maintenance, and the security overhead of managing broad network access. Bastion hosts require dedicated instances, security patching, and key rotation procedures.
Verified Access eliminates both while providing superior security posture. You pay only for active sessions, and AWS handles the infrastructure complexity.
More importantly, the security benefits are immediate. No more “VPN access equals network access.” No more bastion host key management. No more wondering who has access to what, when they accessed it, or whether their device was compromised.
Implementation Strategy
Phase 1: Identify High-Risk Access Patterns – SSH access to production instances – RDP connections to Windows infrastructure – Direct database connections from developer workstations – Administrative access to critical systems
Phase 2: Pilot Verified Access – Start with non-production environments to validate policies – Configure network CIDR targets for existing subnets – Define RDS endpoint targets for database access – Test identity provider integration and device posture checks
Phase 3: Production Deployment – Implement access policies based on principle of least privilege – Monitor access patterns and adjust policies accordingly – Gradually migrate users from VPN/bastion access to Verified Access – Decommission legacy infrastructure once migration is complete
Your Security-Ready Checklist: Actions That Actually Matter
Theory doesn’t prevent breaches. Implementation does. Here’s your prioritized action plan:
| Priority | Task | Impact | Time Investment |
|---|---|---|---|
| Critical | Audit MFA coverage across all root accounts | Prevents account takeover | 2-4 hours |
| Critical | Enable passkey MFA for root and critical IAM users | Eliminates phishing risk | 4-8 hours |
| High | Disable passwords/access keys for member root accounts | Reduces attack surface | 1-2 hours |
| High | Pilot Verified Access for SSH/RDP access | Replaces VPN complexity | 8-16 hours |
| Medium | Implement device posture checking | Prevents compromised device access | 4-8 hours |
| Medium | Decommission legacy bastion hosts | Eliminates maintenance overhead | 8-16 hours |
Critical Actions (Do This Week)
MFA Audit and Implementation – Generate reports of all accounts without MFA – Prioritize root accounts and users with administrative privileges – Enable passkeys using AWS console: IAM → Users → Security credentials → Assign MFA device – Configure backup authentication methods for recovery scenarios
Organization-Level Controls – Enable centralized root access management in AWS Organizations – Document new authentication requirements for security teams – Update incident response procedures to account for passkey recovery
High-Priority Actions (Do This Month)
Verified Access Pilot – Identify 5-10 users who regularly SSH into production instances – Configure Verified Access with your existing identity provider – Define access policies that match current permissions but with device posture requirements – Test access flows and gather user feedback
Legacy Infrastructure Assessment – Document current VPN usage patterns and costs – Identify bastion hosts and their maintenance requirements – Calculate potential savings from infrastructure consolidation
Medium-Priority Actions (Do This Quarter)
Full Verified Access Migration – Expand pilot to all SSH/RDP access patterns – Implement RDS endpoint access for database connections – Configure monitoring and alerting for access pattern anomalies – Begin decommissioning VPN infrastructure
Security Monitoring Enhancement – Integrate Verified Access logs with your SIEM – Set up alerts for unusual access patterns or device failures – Train security team on new access control paradigms
The Reality Check: What Happens If You Don’t Act
Organizations that delay implementing these security improvements face compounding risks:
Financial Impact: The average cost of a cloud security breach now exceeds $4.8 million, with AWS account compromises often leading to cryptocurrency mining charges that can reach tens of thousands of dollars within hours.
Compliance Consequences: Auditors are beginning to expect passkey implementation and zero-trust access controls. Organizations still relying on SMS MFA and VPN access are increasingly flagged for security deficiencies.
Competitive Disadvantage: While you’re managing VPN complexity and recovering from SMS-based phishing attacks, your competitors are deploying infrastructure faster with better security posture.
Operational Overhead: Every month you delay migration to Verified Access is another month of VPN maintenance, bastion host patching, and complex key management procedures.
Building Your Security-First Future
The security landscape has fundamentally shifted. AWS has provided the tools to build cryptographically secure, zero-trust access to your cloud infrastructure. The question isn’t whether you’ll implement these changes—it’s whether you’ll implement them before or after your next security incident.
Strong authentication through passkeys eliminates the most common attack vector against cloud accounts. Zero-trust access through Verified Access eliminates the complexity and risk of traditional network security approaches.
Organizations that implement both gain a significant competitive advantage: faster deployment cycles, reduced operational overhead, and security posture that becomes a business enabler rather than a constraint.
Your Next Steps:
1. This Week:
Complete the MFA audit and enable passkeys for all root accounts
2.
This Month: Pilot Verified Access for your most
critical infrastructure access patterns
3. This
Quarter: Complete migration to zero-trust access and
decommission legacy security infrastructure
The companies that will dominate their markets in 2025 and beyond are those that turn security from a cost center into a competitive advantage. AWS has given you the tools. The only question is how quickly you’ll implement them.
Building secure, scalable AWS architectures requires more than just implementing the latest security features—it requires understanding how these tools fit into your broader business strategy. ZirconTech helps organizations implement these advanced security capabilities while maintaining the agility that makes cloud computing valuable.