8.2.4 is difficult to verify

[jmanico]

8.2.4 Verify that adaptive security controls based on a consumer's environmental and contextual attributes (such as time of day, location, IP address, or device) are implemented for authentication and authorization decisions, as defined in the application's documentation. These controls must be applied when the consumer tries to start a new session and also during an existing session.

Per #3048 I think using IP for auth is a bad idea.

[elarlang]

I re-use my comment from #3048 (comment)

https://pages.nist.gov/800-63-4/sp800-63a.html

Section: https://pages.nist.gov/800-63-4/sp800-63a.html#csp-fraud-management

6. CSPs SHOULD implement - but are not limited to - the following fraud checks for their identity proofing processes based on their available identity proofing types, selected technologies, evidence, and user base:

• Transaction Analytics – Evaluate anticipated transaction characteristics – such as IP Addresses, geolocations, and transaction velocities – ...

---

https://pages.nist.gov/800-63-4/sp800-63b.html

Section: https://pages.nist.gov/800-63-4/sp800-63b.html#AAL_SEC4

At all AALs, pre-authentication checks MAY be used to lower the risk of misauthentication. For example, authentication from an unexpected geolocation or IP address block (e.g., a cloud service) might prompt the use of additional risk-based controls.

Section: https://pages.nist.gov/800-63-4/sp800-63b.html#throttle

Additional techniques MAY be used to reduce the likelihood that an attacker will lock the legitimate claimant out due to rate limiting. These include:

• Accepting only authentication requests from IP addresses from which the subscriber has been successfully authenticated before
• Leveraging other risk-based or adaptive authentication techniques to identify user behavior that falls within or outside typical norms (e.g., the use of the claimant’s IP address, geolocation, timing of request patterns, or browser metadata)

Section: https://pages.nist.gov/800-63-4/sp800-63b.html#binding

The record created by the CSP SHALL contain the date and time of significant authenticator life cycle events (e.g., binding to the subscriber account, renewal, update, expiration). The record SHOULD include information about the source of the binding (e.g., IP address, device identifier) of any device associated with the event.

---

So my proposal is - in case we want to have this requirement, then the IP address fits there and is correct to track it. The "IP address" in the requirement is not the only parameter for authentication or authorization decisions or anything else that is against zero-trust, it is just an extra parameter to follow and monitor.

[jmanico]

What I am citing in NIST 800-63b is:

1. Section 5.1.1.2

“Information such as IP addresses, email addresses, or telephone numbers that can be easily spoofed SHALL NOT be used to determine the binding of authenticators or to validate addresses of record.”

And the requirement starts with:

8.2.4 Verify that adaptive security controls based on a consumer's environmental and contextual attributes (such as time of day, location, IP address, or device) are implemented for authentication and authorization decisions...

Which is literally a direct violation of what NIST is suggestion and I think the wording of the requirement does not match the intention you are stating, Elar. I suggest a word change to clarify that.

[elarlang]

Are you talking about requirement 6.8.1 then?

6.8.1 Verify that, if the application supports multiple identity providers (IdPs), the user's identity cannot be spoofed via another supported identity provider (eg. by using the same user identifier). The standard mitigation would be for the application to register and identify the user using a combination of the IdP ID (serving as a namespace) and the user's ID in the IdP.

[elarlang]

You claim, that it comes from NIST 800-63B:

• https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver - version 3, there is no quoted text in the document and nothing about it in this section
• https://pages.nist.gov/800-63-4/sp800-63b.html - version 4 (draft), there is no quoted text and no section 5.1.1.2.

Can you provide a link, from where you copy it?

Have you read all other mentions about IP addresses from the NIST 800-63B?

[jmanico]

You're right, that was a bad quote. This came from an earlier draft of the identity proofing part of NIST 800-63-A Revision 3 (early draft).

So back the the latest version of 800-63A.

Section 4.4.1.6 (Address Confirmation) of 800-63A removed the IP address quote and simply states:

4.4.1.6 Address Confirmation:

1. Valid records to confirm address SHALL be issuing source(s) or authoritative source(s).
2. The CSP SHALL confirm address of record. The CSP SHOULD confirm address of record through validation of the address contained on any supplied, valid piece of identity evidence. The CSP MAY confirm address of record by validating information supplied by the applicant that is not contained on any supplied piece of identity evidence

There’s no mention of IP, email, or phone as invalid inputs - it’s does not take a stand (any more) about which communication mechanisms are strong/weak.

But NIST broadly requires resistance to spoofing, impersonation, and man-in-the-middle attacks across 800-63A and 800-63B. Under that criteria, IP addresses are implicitly inadequate, but not explicitly banned.

[jmanico]

So all I want to suggest is that we clarify the danger of IP for Auth.

Perhaps:

Verify that adaptive security controls based on a consumer's environmental and contextual attributes (such as time of day, location, IP address, or device) are implemented for authentication and authorization decisions, as defined in the application's documentation. These controls must be applied when the consumer tries to start a new session and also during an existing session. Please note that you should not use an IP address as a sole factor for identity or authorization.

[elarlang]

You're right, that was a bad quote. This came from an earlier draft of the identity proofing part of NIST 800-63-A Revision 3 (early draft).

As we had a similar situation just weeks ago, it sounds... quite bad.

My main point stands - 8.2.4 uses IP address just as an extra parameter to "fingerprint" the user, as the "environmental and contextual attributes" state. It does not allow any auth* decision based only on IP address. So I can not see the problem to solve here.

The message behind the "bad quote" that was talking about spoofing was for identifying the user, and for that ,we have a separate requirement 6.8.1 that I already quoted before: #3071 (comment)

Proposal from me is no action to take.

[jmanico]

First of all you were very correct when it comes to current NIST documentation. I am on vacation using my cell phone and I'll be more careful with citations as I have in other comments.

But I am not ready to close this issue. My concern is fair and still stands. I still want this requirement clarified. The requirement by my read still implies that IP is acceptable for Auth, rate limiting or logging correlation - which is all problematic - and I want to add clarification to this requirement.

Let me explain why.

I used to work for an Internet portal that had over 70 million unique user a month. I was tasked as a security engineer to build a security layer that would block IP addresses when we were getting hit by brute force and other obvious attacks.

We found out two things. (1) Sometimes we would start blocking IP addresses when a threat agent was using a dynamic IP service and we would block a large range of IP addresses for no good reason. (2) we would sometimes block IP addresses that would block many thousands of users from a company or in one case we actually blocked many millions of users from an entire country just by blocking a few IP addresses. (3) We could not rely on IP addresses for log correlation, rate limiting and similar unless we researched the source of the IP addresses first which was non-trivial.

It's this very memorable experience why I get concerned about using an IP address for various security activities. You need to research where that IP address is coming from to see if it's from a consumer IP address range, or is it from a business, or is it from internet provider with dynamic outbound IP addresses or is it from some country-wide firewall and to do so is non-trivial.

[elarlang]

Although I already quote it, requirement 8.2.4 is matching with NIST statement:

https://pages.nist.gov/800-63-4/sp800-63b.html#AAL_SEC4

At all AALs, pre-authentication checks MAY be used to lower the risk of misauthentication. For example, authentication from an unexpected geolocation or IP address block (e.g., a cloud service) might prompt the use of additional risk-based controls.

[jmanico]

I agree IP has its place in security verification. I've built such systems before and especially for internet facing systems it's extremely complex.

I changed the title of this issue as I think more about this thread. My bigger issue is how complex this requirement is and how unverifiable it is, as it stands today, since this is a fairly vague requirement.

• Developers may not know what technical controls are in scope.
• Testers may not know what outcome to verify or what success looks like.
• Product owners will struggle to scope effort or create measurable acceptance criteria.

To truly satisfy this requirement one would need to document:

• Which contextual attributes are mandatory vs. optional
• What constitutes an “adaptive security control” in more concrete terms
• How frequently or under what conditions evaluation must occur during an active session
• What actions are expected upon risk detection (e.g., session termination, step-up authentication, logging, alerting)

... and a whole lot more.

In its current form, the requirement describes "architectural intent" rather than a verifiable outcome. It reads more as a security objective than an verifiable implementation requirement.

But I do think this is a very important requirement for zero trust networks and similar.

How can we make this more verifiable? Perhaps:

Verify that authentication and authorization decisions incorporate adaptive security controls that evaluate one or more contextual factors (e.g., IP address, device fingerprint, location, time of day). Ensure that these evaluations must occur at the start of a new session and at least once during an active session, either periodically or triggered by defined risk events. Ensure that the specific attributes evaluated, thresholds for risk, and actions taken (e.g., allow, challenge, deny, step-up authentication) are all documented.

[elarlang]

That is a nice explanation why we need documentation requirements - otherwise no one knows how to implement or test those requirements, and we have it covered by:

8.1.3 Verify that authorization documentation defines a consumer's environmental and contextual attributes (such as time of day, location, IP address, or device) that must be used in the application to make security decisions, including those pertaining to authentication and authorization.

[jmanico]

As I've said many times, access control is one of the few places where documentation is prudent. Especially when it's complex like zero trust and adaptive controls.

But as stands now, we are avoiding the issue. We say "document it yourself and then verify what you wrote" with very little guidance. And that does not help lead to secure outcomes, nor does it give advice to how to go about documenting these complex issues.

If you really want to keep this requirement, which I think is a good idea, I suggest we explain what needs to be documented like I described above, instead of the very vague requirements we have in this area today.

[tghosth]

These are the requirements we currently have:

#	Description	Level	#v5.0.be
8.1.3	Verify that authorization documentation defines a consumer's environmental and contextual attributes (such as time of day, location, IP address, or device) that must be used in the application to make security decisions, including those pertaining to authentication and authorization.	3	v5.0.be-1.4.6
8.1.4	Verify that authorization documentation considers environmental and contextual factors in decision-making, in addition to function-level, data-specific, and field-level authorization.	3	v5.0.be-1.4.9
8.2.4	Verify that adaptive security controls based on a consumer's environmental and contextual attributes (such as time of day, location, IP address, or device) are implemented for authentication and authorization decisions, as defined in the application's documentation. These controls must be applied when the consumer tries to start a new session and also during an existing session.	3	v5.0.be-4.1.8

Having read the above and re-read the requirements, I would suggest some minor tweaks.

#	Description	Level	#v5.0.be
8.1.3	Verify that the application's documentation defines the a consumer's environmental and contextual attributes (such as including but not limited to, time of day, user location, IP address, or device) that are must be used in the application to make security decisions, including those pertaining to authentication and authorization.	3	v5.0.be-1.4.6

I think this requirement is about documenting which contextual attributes are taken into account, not how they are taken into account.

#	Description	Level	#v5.0.be
8.1.4	Verify that authentication and authorization documentation considers defines how environmental and contextual factors are used in decision-making, in addition to function-level, data-specific, and field-level authorization. This should include the attributes evaluated, thresholds for risk, and actions taken (e.g., allow, challenge, deny, step-up authentication.)	3	v5.0.be-1.4.9

I want to make this requirement about authentication as well and here I add Jim's points requiring more details on how these attributes are evaluated as this is where we actually require using the contextual attributes.

I think that these requirements perfectly set up 8.2.4 so not sure I would suggest any changes to that.

[elarlang]

8.1.3 changes are good.

8.1.4 - if you make this requirement valid for authentication, then it may be not found from the authrization chapter.

[jmanico]

8.1.3 changes are good.

8.1.4 - if you make this requirement valid for authentication, then it may be not found from the authorization chapter.

I like these changes as well. Perhaps split 8.1.4 into AuthN and AuthZ requirements?

For 8.2.4 I would also suggestion moving "These controls must be applied when the consumer tries to start a new session and also during an existing session." from 8.2.4 and move that section to a documentation requirement because there are a lot of factors that go into this mechanism. Questions for implementors will come up like:

• Which user‑ or device‑attributes (IP, geolocation, device fingerprint, time‑of‑day, behavioral biometrics, etc.) will we monitor at session start?
• Which of those signals need to be refreshed during an active session, and at what cadence?
• How will we ensure each signal’s accuracy and handle missing or low‑confidence data?
• What scoring model (weights, thresholds, ML, rule‑based, hybrid) will convert raw signals into a risk tier?
• Where will the model run (edge, API gateway, central service), and what is our latency budget?
• What action maps to each risk tier (allow, CAPTCHA, step‑up MFA, block, revoke session)?
• What user‑facing messages and error codes will accompany each action?
• At which exact code or platform layers will we invoke the risk engine (login controller, middleware, API gateway, service mesh)?
• How do we propagate decisions consistently across web, mobile, and API clients?
• How do we mutate, extend, or revoke tokens/cookies when a mid‑session risk check escalates?
• How do we synchronize state across multiple concurrent devices or browser tabs?

[elarlang]

For 8.2.4 I would also suggestion moving "These controls must be applied when the consumer tries to start a new session and also during an existing session." from 8.2.4

8.2.4 is implementation requirement. Whatever it needs as pre-condition input, must come from documentation requirements, current 8.1.*.

[tghosth]

8.1.4 - if you make this requirement valid for authentication, then it may be not found from the authrization chapter.

I think we need to solve this with section text.

I like these changes as well. Perhaps split 8.1.4 into AuthN and AuthZ requirements?

I think this will just cause duplication without a significant difference in requirement.

For 8.2.4 I would also suggestion moving "These controls must be applied when the consumer tries to start a new session and also during an existing session." from 8.2.4 and move that section to a documentation requirement because there are a lot of factors that go into this mechanism.

8.2.4 is implementation requirement. Whatever it needs as pre-condition input, must come from documentation requirements, current 8.1.*.

@elarlang are you agreeing with Jim that the text should move into 8.1.4?

Questions for implementors will come up like:

I think these are beyond the scope of an ASVS requirement. Can I suggest that I PR these into the Authentication Cheat Sheet and include a reference here?

[elarlang]

@elarlang are you agreeing with Jim that the text should move into 8.1.4?

No, if the statements starts with "These controls must be applied" it is a clear implementation requirement not something you need to document extra. If 8.1.4 missing some key points, it can be added there without taking it away from 8.2.4.

The path here so far: #3048 "IP is bad" > "IP in auth is bad" > #3071 > "NIST says this" > "Ok, it did not say this, it was a bad quote" > "8.2.4 is bad" > "8.2.4 requires documentation" > "There is documentation.. but it does not provide guidance." > "Let's move at least some part somewhere."

Really hard to see what is the actual problem to solve here. If we can stop this cycle without inventing new "problem to solve", it would be nice.

[tghosth]

Opened #3086 to resolve locally and I opened 1657 to add content to cheatsheets.

[jmanico]

Thank you @tghosth I appreciate how you resolved my concerns here.