Notifications
Clear all
Topic starter
11/07/2026 8:26 pm
TL;DR: Static sign-in checks are no longer enough for apps that need to step up authentication mid-session based on device, location, and transaction context, according to Authsignal. The real governance shift is that identity controls must follow user intent and risk state, not stay fixed at login.
NHIMG editorial — based on content published by Authsignal: Building adaptive authentication with Amazon Cognito and Authsignal
By the numbers:
- If payment amount > $1000 AND user is on a new device, require passkey authentication
Questions worth separating out
Q: How should security teams implement adaptive authentication in Cognito-based applications?
A: Start by defining which actions deserve step-up authentication, then wire those checkpoints into the sign-in flow or backend API calls.
Q: When does sign-in-only MFA stop being enough for user protection?
A: Sign-in-only MFA stops being enough when the application contains valuable post-login actions such as payments, beneficiary changes, or security-setting updates.
Q: What do teams get wrong about risk-based authentication policies?
A: Teams often hard-code risk thresholds into application logic and then treat them as fixed.
Practitioner guidance
- Map step-up triggers to business actions Identify the specific transaction types, account changes, and security-setting updates that should require reauthentication.
- Separate policy ownership from application releases Give fraud or security teams the ability to adjust challenge thresholds, device rules, and recency windows without a full code deployment.
- Instrument context signals before enforcing rules Collect device, location, transaction, and session recency data consistently before you turn on adaptive challenges.
What's in the full article
Authsignal's full post covers the implementation detail this analysis intentionally leaves for the source:
- Lambda trigger setup for Cognito challenge and verification flows
- Concrete rule examples for payments, new devices, and security-setting changes
- Application-side API patterns for triggering challenges after sign-in
- Operational guidance for combining prebuilt UI and custom UI challenge paths
👉 Read Authsignal's implementation guide for adaptive authentication with Cognito →
Adaptive Cognito authentication: are your controls keeping up?
Explore further
11/07/2026 8:56 pm
Static authentication is a poor fit for high-risk user journeys. The article shows why sign-in alone does not describe the real trust problem in modern applications. Once a session is established, the risk posture can change with device, amount, location, and recent activity. That means the governance unit is no longer the login event, it is the action being attempted. Practitioners should treat authentication as a sequence of decisions, not a single gate.
A few things that frame the scale:
- 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.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
A question worth separating out:
Q: How do you know if continuous authentication is working?
A: Look for whether step-up challenges are concentrated around genuinely sensitive actions, not scattered across low-risk journeys. Effective continuous authentication should reduce high-risk abuse without creating excessive friction for normal users. If the challenge rate is detached from business risk, the policy needs adjustment.
👉 Read our full editorial: Adaptive authentication for Cognito still needs runtime risk signals
