A successful login establishes authentication.
It should not automatically mean that every action in that session deserves the same level of trust.
Consider two users:
- One logs in from a familiar device and checks transaction history.
- Another logs in after account recovery, from a new device, and immediately attempts to change the registered mobile number or add a beneficiary.
Both may have successfully authenticated.
But the required assurance for their next actions can be very different.
Authentication Is Only One Layer
A useful architecture separates:
Identity
↓
Authentication
↓
Session Assurance
↓
Action Authorization
`
The risk layer can evaluate contextual evidence such as:
- device history
- app-integrity signals
- network reputation
- recent account recovery
- authentication method
- behavioral anomalies
- requested operation
- transaction context
But the risk engine should provide evidence, not become the final security authority.
The policy layer should decide whether the requested operation is:
text
ALLOW
STEP_UP
RESTRICT
DENY
Keep Sensitive Decisions on the Backend
The mobile application can collect security signals, but sensitive authorization decisions should remain on trusted backend infrastructure.
For request-specific security evidence, the backend should also validate:
- freshness
- request or challenge binding
- server-side account state
- current session assurance
Client-side checks can improve UX, but they should not become the final authorization boundary.
Step-Up Should Actually Increase Assurance
An additional challenge is useful only when it meaningfully strengthens confidence.
Repeating the same potentially compromised credential may add little protection.
Depending on the threat model, stronger verification may involve cryptographic authenticators, device-bound credentials, or transaction-specific confirmation.
The objective is not more friction.
It is sufficient assurance for the action being attempted.
Trust Can Change During a Session
A session can begin normally:
text
09:00 Login
09:02 View balance
09:05 Change email
09:07 Add beneficiary
09:08 Initiate large transfer
The security context at 09:08 is no longer necessarily the same as it was at 09:00.
Sensitive account changes can reduce the assurance the system is willing to rely on.
This is why adaptive authentication works better when trust is treated as mutable state rather than a permanent login property.
Authentication Is Not Enough for Financial Execution
Sensitive financial operations also need protection against:
- replay
- duplicate retries
- stale authorization
- concurrent requests
- invalid workflow transitions
- partial dependency failures
Authentication and authorization therefore need to work alongside transaction-state validation, idempotency, and atomic backend execution.
The Core Principle
The better question is not only:
Did this person log in successfully?
It is:
How much confidence do we have in this session right now, and is that confidence sufficient for what the user is about to do?
Adaptive authentication is not about challenging users more often.
It is about applying the right level of assurance to the right action at the right time.
Read the full article on Medium:
Top comments (0)