Adaptive MFA at the CloudFront edge for legacy web apps

At a glance

What this is: This is a step-by-step pattern for adding adaptive MFA and passkeys at CloudFront without modifying the origin application, with risk decisions handled at the edge.

Why it matters: It matters because many IAM teams need to raise authentication assurance across legacy, third-party, or hard-to-change apps without waiting for application refactoring or backend coordination.

👉 Read Authsignal’s guide to adding adaptive MFA and passkeys at the CloudFront edge

Context

Adaptive MFA at the edge is a way to enforce stronger authentication before a request reaches the application’s own login logic. The pattern matters because the current control point in many environments is still the app itself, which makes MFA retrofits slow when the codebase is old, the app is third-party, or the auth layer is owned by another team.

For IAM and security teams, the practical issue is not just adding another factor. It is preserving login flow, session continuity, and user experience while moving the authentication decision to a place the organisation can actually control. That makes CloudFront, session handling, and edge state management part of the identity design, not just the deployment architecture.

Key questions

Q: How should security teams add MFA to legacy apps without changing the origin?

A: Place the authentication decision at the front door, such as CloudFront or another reverse proxy layer, and preserve only the minimum state needed to complete the login flow. Encrypt any temporary data, keep challenge state short-lived, and test the full redirect path so the origin remains unchanged but the sign-in policy is still enforced.

Q: Why do edge-based authentication controls matter for IAM programmes?

A: They matter because many applications cannot be refactored quickly, yet the organisation still needs stronger sign-in assurance. Edge-based controls let IAM teams enforce adaptive MFA across legacy, third-party, and hard-to-own apps without waiting for backend changes, which makes identity policy more operationally flexible.

Q: What do teams get wrong about adding MFA to existing applications?

A: They often assume the application must own every step of authentication. In practice, the control can sit in the delivery layer if session continuity, encryption, and redirect handling are designed correctly. The failure mode is usually not MFA itself, but broken state management around the login flow.

Q: Who should own risk-based MFA when the application does not change?

A: Ownership should sit with the team responsible for authentication policy, edge enforcement, and operational testing, not only with the application owner. If the origin never sees the MFA step, governance must cover who approves policy changes, who monitors failures, and who validates that challenge behaviour matches risk intent.

Technical breakdown

Why the edge becomes the auth control point

Lambda@Edge lets authentication logic run at CloudFront stages before or after the origin processes a request. In this pattern, the viewer request function captures the username, the origin response function makes the risk decision, and the origin request function restores the session after MFA. The origin application does not need new routes or auth code. That matters because it moves policy enforcement outside the app while still preserving a normal login sequence. The design depends on cookies as the only shared state between functions, which makes encryption and idempotency essential rather than optional.

Practical implication: teams can centralise MFA enforcement for hard-to-change apps without waiting for application code changes.

How state is preserved without sharing memory

Lambda@Edge functions cannot share memory or environment variables, so the implementation uses encrypted cookies to pass usernames, challenge metadata, and session state between independent edge functions. The origin response function stores the original 302 session cookies inside an encrypted challenge cookie, then the return leg decrypts that state after the user completes MFA. This is a fragile but workable pattern because the edge is stateless by design. If encryption, cookie handling, or redirect logic fails, the login flow breaks even if the risk engine is functioning correctly.

Practical implication: identity teams must treat cookie encryption and redirect continuity as first-class controls, not implementation details.

Risk-based MFA is different from forcing MFA on every sign-in

The article’s key architectural point is adaptive decisioning. Authsignal evaluates the login context after the origin returns a successful authentication response, then decides whether to ALLOW or CHALLENGE_REQUIRED. That means MFA can be applied selectively based on risk rather than universally at the first step. This pattern is useful for legacy apps and sudden security responses after credential stuffing, because it can add friction only where needed. But it also means the risk decision is now part of the authentication path, so availability, latency, and error handling become identity controls as well.

Practical implication: teams should validate risk-policy behaviour under failure, not just under ideal challenge flows.

Threat narrative

Attacker objective: The attacker aims to turn a successful password-only login into a valid session without triggering additional verification.

1. Entry occurs when a user submits credentials to the login form and the edge function intercepts the POST request before it reaches the origin.
2. Escalation occurs if the login is successful but no adaptive challenge is inserted, allowing the session to continue with only the original credential assurance level.
3. Impact is the absence of step-up authentication for risky sessions, which leaves account takeover risk unmitigated even though the application believes the login succeeded.

Breaches seen in the wild

• SpotBugs Token GitHub Supply Chain Attack — Leaked SpotBugs personal access token triggers cascading GitHub supply chain attack across thousands of repositories.
• GitHub Personal Account Breach — Compromised GitHub personal access token enables clone of Desktop and Atom repositories with signing certificates.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authentication control is moving out of the app and into the delivery layer. This pattern reflects a broader shift in identity architecture: the application no longer has to own every step of authentication to enforce policy. That matters for legacy tools, third-party apps, and environments where source changes are slow or impossible. The real change is governance, because the control point becomes CloudFront state handling, not application code. Practitioners should treat the edge as an identity enforcement layer, not just a traffic layer.

Session continuity is now an identity design requirement, not a UX detail. The article shows that MFA insertion can preserve original session cookies, redirect destinations, and idempotency if the edge functions are carefully coordinated. That is a useful pattern for operational adoption, but it also means identity teams must govern how state is encrypted, stored, and restored across independent execution steps. The lesson is that authentication assurance and session integrity are coupled, especially when the app itself remains unchanged.

Adaptive MFA reduces retrofitting friction, but it does not remove the governance burden. Teams still have to decide which requests merit challenge, how to handle failures, and where the authoritative identity state lives when the origin is unaware of the step-up. The operational implication is that authentication policy becomes distributed across infrastructure, edge code, and the risk engine. That makes policy drift and inconsistent challenge behaviour the new failure modes to watch.

Edge-based MFA exposes a governance gap between access policy and application ownership. Many IAM programmes assume the application team must participate in every authentication change. This pattern breaks that assumption by letting security enforce stronger sign-in controls without altering the origin. The implication is that organisations need a clear operating model for who owns edge authentication logic, who tests it, and who signs off when login assurance changes outside the app team.

Runtime auth decisions now belong in the same conversation as workload identity and secrets handling. The implementation relies on API secrets, encrypted cookies, and function isolation, which means identity and infrastructure controls are intersecting at the same point of failure. For practitioners, the lesson is that MFA insertion at the edge should be reviewed alongside secret management, logging, and CloudFront policy design, not treated as a standalone auth feature.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For a deeper NHI control lens, review Ultimate Guide to NHIs , The NHI Market to connect access policy decisions with broader identity governance.

What this signals

With 27-day secret remediation timelines still sitting alongside 75% confidence in secrets management, the practical lesson is that identity control often lags the pace of exposure. Edge-based MFA can reduce authentication risk, but it does not fix the broader governance problem of delayed response, weak ownership, and fragmented control points across identity layers.

Control-plane authentication drift: when the identity decision moves to CloudFront or another edge layer, governance has to follow it. The organisation must know who owns challenge policy, how rollback works, and what logging proves that the edge is enforcing the intended access model.

The forward signal for IAM teams is clear: authentication is becoming distributed across application, edge, and policy services, so operating models need to be explicit about control ownership. That makes policy review cadence, secret handling, and incident validation part of the same programme, not separate disciplines.

For practitioners

• Map which apps can absorb edge-layer MFA Identify legacy, third-party, and source-locked applications where CloudFront or another front door can become the policy enforcement point without changing the origin application.
• Separate challenge state from application session state Encrypt usernames, challenge metadata, and session cookies before passing them between edge functions, and define a short-lived cleanup path for any temporary cookies.
• Test the full redirect and restore path under failure Validate what happens when the risk API times out, the callback token is missing, or the encrypted challenge cookie cannot be read, because broken restore logic becomes an auth outage.
• Treat CloudFront policy choices as identity controls Review cache behaviour, body forwarding, host preservation, and Lambda@Edge versioning as part of the access model, because each setting affects whether authentication can complete correctly.

Key takeaways

• Adaptive MFA at the edge can secure legacy and third-party apps without rewriting the origin application.
• The hard part is not inserting a challenge, but preserving state, redirects, and session integrity across stateless edge functions.
• IAM teams should treat CloudFront policy, cookie handling, and secret management as core authentication controls, not implementation details.

Key terms

• Adaptive MFA: Adaptive MFA is multi-factor authentication that changes its challenge based on risk signals such as location, device, or session context. It reduces unnecessary friction while still stepping up assurance when the login looks abnormal or high-risk.
• Lambda@Edge: Lambda@Edge is AWS's way to run Lambda functions at CloudFront request and response stages. For identity teams, it matters because authentication decisions can be enforced at the delivery layer before the origin application ever sees the request.
• Session Continuity: Session continuity is the ability to preserve a valid login flow while adding an extra verification step. In edge-based MFA patterns, the challenge is to maintain redirect targets and session cookies without exposing sensitive state or breaking the application journey.
• Challenge State: Challenge state is the temporary data that ties a login attempt to an MFA step, including identifiers, redirect location, and proof that the challenge belongs to the same session. In edge designs, it must be short-lived, encrypted, and carefully cleared after use.

What's in the full article

Authsignal's full blog post covers the operational detail this post intentionally leaves for the source:

• The complete Lambda@Edge implementation pattern, including the three function roles and how each one handles the login flow.
• The shared utility code for encryption, cookies, and HTTPS calls, which is useful if you need to reproduce the edge pattern safely.
• The CloudFormation and SAM deployment details, including versioning, origin policy choices, and CloudFront association settings.
• The testing and configuration steps for Authsignal rules, passkeys, OTP, and challenge policy behaviour.

👉 The full Authsignal post covers the edge functions, encrypted session handling, and deployment details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.