ASVS 5.0 V8.2.4 asks for adaptive security controls: decisions that change based on a consumer's context, such as time of day, location, IP address or device. It is Level 3, so it targets high-assurance systems. The controls must apply when a session starts and again during the session, and they must match what your documentation says.
Why it matters
A valid password or token proves little about who is holding it. A session cookie replayed from another continent twenty minutes after the real login looks identical to the original until you compare context.
How to implement it
Write down the rules first. The standard says the controls are "as defined in the application's documentation", so a documented policy is part of the requirement.
At login, score the attempt. At each sensitive request, re-score it against the session's baseline.
def evaluate(session, request):
signals = {
"new_device": request.device_id not in session.known_devices,
"ip_changed": request.ip_prefix != session.ip_prefix,
"geo_jump": distance_km(session.geo, request.geo) > 1000,
"off_hours": not within_working_hours(session.user, request.time),
}
score = sum(signals.values())
if score >= 3:
return "deny"
if score >= 1 and request.is_sensitive:
return "step_up" # require a fresh MFA challenge
return "allow"
Log every non-allow decision with the signals that caused it.
How to test it
Replay one session cookie from a different IP and user agent and confirm the step up or deny result. Use a VPN to simulate a geo jump. Run a sensitive action outside the documented hours. Confirm the same rules fire mid-session, not only at login.
Common mistakes
- Checking context only at login.
- Trusting
X-Forwarded-Forfrom any client. - Hard blocking on weak signals, which locks out travelers and teaches users to ignore alerts.
- Having rules that exist in code but nowhere in documentation.
Quick check
Is a login time check enough for V8.2.4?
No. The requirement covers both session start and the existing session.
