Topic starter
10/07/2026 9:26 pm
TL;DR: Risk-based MFA can be added to existing web apps without changing the origin, using encrypted cookies and three edge functions to preserve login state while inserting challenge decisions at CloudFront, according to Authsignal. The governance question is not whether MFA works, but where authentication control can be inserted without breaking application ownership and session handling.
Editorial analysis by NHI Mgmt Group, based on content published by Authsignal: “How to add adaptive MFA and passkeys to any web app with Authsignal and Lambda@Edge”.
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.
Q: Why does adaptive MFA at the edge change IAM governance decisions?
A: Because the authentication control is no longer owned only by the application team.
Q: What breaks when edge functions cannot share login state safely?
A: The challenge flow breaks if usernames, session cookies, or redirect context are not preserved and restored correctly.
Practitioner guidance
- Define the edge trust boundary Document which authentication decisions are allowed to happen at CloudFront and which must remain in the origin application or identity provider.
- Encrypt all state passed between edge functions Keep usernames, challenge metadata, and session cookies encrypted before they are written into cookies or forwarded between Lambda@Edge stages.
- Preserve redirect integrity Test the login flow end to end so challenge redirects, callback handling, and session restoration survive without breaking user sign-in.
Bottom line: The article shows that MFA can be added to legacy web apps without touching the origin, but only if the edge layer can preserve login state cleanly.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
10/07/2026 9:48 pm
Control placement is now an identity-governance decision, not just an implementation detail. The article shows that MFA can be enforced outside the origin when the app cannot be touched, which shifts the governance question from "can we add MFA?" to "where can authentication be inserted without breaking ownership and session handling?" For IAM teams, the decision boundary matters as much as the factor itself. The practical conclusion is to govern control placement explicitly.
A few things that frame the scale:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
A question worth separating out:
Q: Should security teams use edge-based MFA as a long-term architecture?
A: Only if they are prepared to govern it as part of the permanent identity model. If it exists only because the origin cannot change, teams should treat it as a controlled bridge and revisit whether the authentication path should eventually move closer to the application or IdP.
👉 Read our full editorial: Adaptive MFA at the CloudFront edge for legacy web apps