Adaptive authentication for Cognito still needs runtime risk signals

At a glance

What this is: This is a practical guide to extending Amazon Cognito with adaptive and continuous authentication for higher-risk actions.

Why it matters: It matters because IAM teams need step-up controls that can react to transaction context, device changes, and session risk without turning every policy change into a code deployment.

By the numbers:

• If payment amount > $1000 AND user is on a new device, require passkey authentication

👉 Read Authsignal's implementation guide for adaptive authentication with Cognito

Context

Amazon Cognito covers baseline user authentication, but many applications need stronger verification when risk changes after sign-in. The gap is not login itself, it is the lack of native, policy-driven step-up controls for sensitive actions such as payments, account changes, or privileged settings.

Adaptive authentication closes that gap by evaluating context like device, location, amount, and recent session activity before deciding whether to challenge the user. For IAM practitioners, the question is how to extend human identity controls beyond static access checks without building a brittle custom challenge flow every time the fraud model changes.

Key questions

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. Keep the decision logic in a policy layer so risk thresholds can change without redeploying the application. The goal is to challenge only when context such as device, amount, or location makes the action materially riskier.

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. In those cases, attackers do not need to defeat login again, they only need a live session. Step-up controls reduce that gap by rechecking trust at the moment of impact.

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. That turns business rules into release-cycle dependencies and makes the control slow to adapt. A better model is to manage authentication policy as a governed rule set with clear ownership, testing, and review.

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.

Technical breakdown

How adaptive authentication layers onto Cognito

Adaptive authentication adds a decision layer on top of the normal Cognito sign-in flow. Cognito still handles primary user authentication, while Lambda triggers or direct API calls can invoke a risk engine at specific points in the session. The engine evaluates signals such as device fingerprint, location, transaction amount, and recent authentication age, then returns a challenge decision. This is different from one-time MFA because the challenge is conditional and can happen after initial login, when business risk actually changes.

Practical implication: model your authentication flow as a sequence of risk checkpoints, not a single login event.

Why no-code rules engines matter for identity governance

A no-code rules engine shifts some authentication policy changes away from code deployments and into policy updates. That matters because many risk thresholds are business decisions, not engineering decisions, and they change faster than release cycles. In identity governance terms, this creates a policy administration layer above the application, where fraud, product, and security teams can define when authentication should step up without rewriting the app each time. The control point becomes the rule itself, not the application code that enforces it.

Practical implication: separate policy ownership from application delivery so authentication thresholds can change without redeploying the product.

Continuous authentication versus sign-in-only MFA

Continuous authentication treats the session as dynamic, which is closer to how real abuse happens. Attackers often pass initial sign-in and then move to high-value actions, so a control that only verifies identity at entry leaves a long exposure window. Continuous checks reduce that window by re-evaluating context when the user attempts something sensitive, such as changing a beneficiary or modifying security settings. In IAM terms, this is a shift from access approval at the door to trust validation throughout the journey.

Practical implication: reserve step-up challenges for actions that change financial, security, or data access risk.

NHI Mgmt Group analysis

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.

Adaptive MFA creates a policy layer that belongs in IAM governance, not app logic. Moving challenge decisions into rules reduces the need to hard-code thresholds into every product flow. It also gives security and fraud teams a clearer governance surface for reviewing when a challenge should occur and who can change that policy. That is a better operating model for shared human identity controls across product and security teams.

Context-aware authentication is really about reducing authentication drift. Once rules depend on device, location, transaction value, and recency, the control must stay aligned with the application’s risk model. Runtime challenge drift: if those conditions are only managed inside code, they become stale as soon as the business changes the threshold or the fraud pattern shifts. Practitioners should govern the rule set as a living control plane.

Continuous authentication validates a broader identity design principle. Access decisions should be proportional to session risk, not fixed at enrollment. That principle applies across consumer IAM, B2B portals, and regulated workflows where the same authenticated user can move from low-risk browsing to high-impact action in seconds. Teams should use this pattern where identity assurance must follow intent, not just identity proofing.

From our research:

• 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.
• That gap between confidence and remediation speed is why practitioners should also review Ultimate Guide to NHIs , The NHI Market for broader identity governance context.

What this signals

Runtime challenge drift: adaptive authentication only works when policy thresholds stay aligned with the application’s changing risk profile. If teams leave those thresholds buried in code, the control becomes stale faster than fraud patterns evolve, and governance loses sight of when step-up rules are actually changing.

For identity programmes, this is a reminder that human authentication is no longer just about login strength. The operational boundary now includes mid-session decisions, so IAM teams should align policy review, telemetry, and exception handling with the same discipline used for other high-impact access controls.

For practitioners

• Map step-up triggers to business actions Identify the specific transaction types, account changes, and security-setting updates that should require reauthentication. Do not attach step-up to every page view; attach it to the actions that materially change fraud or account-takeover risk.
• 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. Keep the policy change process auditable so control updates do not become informal exceptions.
• Instrument context signals before enforcing rules Collect device, location, transaction, and session recency data consistently before you turn on adaptive challenges. If the signals are incomplete, the policy will either over-challenge legitimate users or under-protect sensitive actions.
• Review challenge outcomes as a governance signal Track where users are challenged, where they fail, and where high-risk actions pass without step-up. That data shows whether the policy is aligned with actual attack patterns or just creating friction.

Key takeaways

• Adaptive authentication moves the control point from login to the specific action being attempted.
• The strongest governance benefit is policy agility, because risk thresholds can change without forcing application redeployments.
• Continuous authentication works when it is tied to the right high-risk events and backed by reliable context signals.

Key terms

• Adaptive Authentication: Adaptive authentication is a policy approach that changes the strength of verification based on context such as device, location, transaction value, or session history. In practice, it applies a risk decision at the moment of action instead of relying only on the original login event.
• Continuous Authentication: Continuous authentication re-evaluates trust during an active session, especially before sensitive actions. It is designed to narrow the gap between successful login and high-impact abuse by checking whether the current request still fits the expected user context.
• Step-Up Authentication: Step-up authentication adds a stronger challenge when a user attempts a riskier action than the one they used to sign in. For identity programmes, it is a targeted control that preserves usability while increasing assurance where the business impact is highest.
• Risk-Based Authentication: Risk-based authentication uses contextual signals to decide whether a user should be challenged more aggressively. The control is only as good as the policy logic and the quality of the signals feeding it, which means governance and telemetry matter as much as the authentication method.

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

👉 The full Authsignal post covers the Cognito integration flow, policy examples, and challenge orchestration details.

Deepen your knowledge

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