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.
Editorial analysis by NHI Mgmt Group, based on content published by Authsignal: “Building adaptive authentication with Amazon Cognito and Authsignal”.
Key questions
Q: How should teams implement adaptive authentication for customer identity journeys?
A: Start by mapping the actions that deserve step-up verification, then place the policy in a layer that business or fraud teams can adjust without changing application code.
Q: Why do static login checks fail for sensitive transactions and account changes?
A: Because the risk changes after sign-in even when the user identity does not.
Q: What are the signs that API authentication has become too embedded in application logic?
A: The warning signs are duplicated login checks, inconsistent expiry handling, different cookie or token behaviours across endpoints, and auth code that developers must update whenever session rules change.
Practitioner guidance
- Define step-up triggers by action value Map the exact events that should force re-verification, such as payments above a threshold, beneficiary changes, new-device sign-ins, or security setting updates.
- Separate policy from application code Move adaptive authentication thresholds and rule conditions into a policy layer so fraud and product teams can update decisions without redeploying the app.
- Use runtime context as a control input Feed device, location, transaction amount, and recent behaviour into the authentication decision so the challenge matches the current risk state.
Bottom line: Static sign-in checks do not protect the full user journey when risk changes after authentication.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/07/2026 8:56 pm
Adaptive authentication is really a runtime governance problem, not a login feature. The article shows that Cognito can establish identity, but it does not by itself keep evaluating risk as the user moves through higher-value actions. That distinction matters because many IAM programmes still treat authentication as a front-door control. The practitioner conclusion is that trust has to be re-authorised at the point of action, not assumed from the original sign-in.
A question worth separating out:
Q: What is the difference between step-up authentication and adaptive authentication?
A: Step-up authentication raises the authentication requirement when a user tries to access a more sensitive resource or perform a higher-risk action. Adaptive authentication makes that decision based on the user’s current risk profile, such as location, IP history, or job context. In practice, step-up is resource driven, while adaptive is risk driven.
👉 Read our full editorial: Adaptive authentication for Cognito still needs runtime risk signals