1. Why static lists are necessary but not sufficient

A static IP allow-list is the right answer for credentials with a knowable home, but much of the real attack surface is not allow-listable in advance: public sign-in, partner callbacks, and broadly reachable APIs. For those, you cannot enumerate every good source — but you can react to bad ones, to anomalous origins, and to abusive volume. That reactive judgement is what the adaptive identity firewall adds, without replacing the strict core where the core applies.

2. The static core is never relaxed

The defining rule of this design: the adaptive layer can only add denials, never remove them. If an identity carries a static allow-list, a request from outside it is rejected no matter how clean the adaptive signals look. The shell tightens; it cannot open the vault. This ordering — strict core evaluated first, adaptive judgement second — is what keeps a dynamic system from becoming a soft one.

3. The adaptive shell

Above the core, four signal classes shape the decision:

• Geo and ASN rules — deny or step-up by country or autonomous system, useful for blocking origins a given identity should never legitimately use.
• Auto-expiring threat-intelligence deny feeds — known-bad IPs and ranges are denied, with each entry carrying a time-to-live so the list self-cleans and never ossifies into stale blocking.
• Per-identity and per-endpoint rate limits — abusive volume is throttled or blocked at the identity and the route, defeating brute force and scraping without a global chokepoint.
• Device signals — posture and recognition feed both denial and step-up, sharing the signal set the risk-adaptive MFA reads.

4. Fail-closed and feed hygiene

Two operational disciplines keep the adaptive layer trustworthy. First, fail-closed on the things that must not fail open: a malformed or unreachable signal source must not silently downgrade enforcement on sensitive operations. Second, feed hygiene: deny-feed entries expire by TTL so the firewall reflects current intelligence rather than an ever-growing scar of old blocks — stale denials are as much an availability bug as a security one.

5. The calling convention

The adaptive layer is configured as policy over signal sources; the static core is untouched.

// Adaptive shell over the strict allow-list core — deny-union semantics
services.AddB5SecurityKit(o => {
  o.IdentityFirewall.Geo        = GeoPolicy.DenyList("by-identity");
  o.IdentityFirewall.ThreatFeed = Feed.AutoExpiring(ttl: TimeSpan.FromHours(24));
  o.IdentityFirewall.RateLimit  = Limit.PerIdentity(600).PerEndpoint(60);
  o.IdentityFirewall.OnSignalFailure = FailMode.Closed; // never downgrade sensitive ops
});

6. What an attacker actually gets

An attacker scanning from a flagged range is denied by the threat feed; one rotating through a hostile ASN is caught by the ASN rule; one brute-forcing a login is throttled by the per-endpoint limit before it gets far; one on an unrecognized device is pushed into step-up. And if the targeted identity has a static allow-list, none of the attacker’s maneuvering matters — the strict core denied them first. The adaptive layer raises cost across the board while the core holds the hard line.

7. Where this lands in an audit

This is the evidence for threat-aware network defense, anti-automation, and adaptive access control (NIST CSF PR.IR / DE.CM; SOC 2 CC6.6, CC7.2; ISO 27001 A.8.20–A.8.23). Reviewers probing defense-in-depth get a clean story: a rigid core for what can be enumerated, an intelligent shell for what cannot, and an explicit rule that the shell can only tighten.

Next: Rules-Based Suspension — revoke exactly what’s wrong →