Bind credentials to known ground.
Static IP allow-lists, applied per identity across the whole pipeline, bind a sensitive credential to the networks it is allowed to operate from — so a leaked key is useless from anywhere else. This strict, deny-by-default core is the foundation the adaptive identity firewall layers on top of; it is the ground truth that never moves.
1. Why bind credentials to networks
A secret that works from anywhere is a secret whose blast radius is the entire internet. The single cheapest way to shrink that radius is to declare where a credential is allowed to be used at all. A service key that integrates two back-end systems has a knowable set of source networks; an administrative session originates from a knowable corporate range. Binding the credential to those networks turns a leaked secret from a master key into a key that only works from a place the attacker is unlikely to be.
2. Today: per-identity allow-lists
B5 Secure enforces static IP allow-lists per identity — applied equally to API keys and to high-privileged user sessions — uniformly across the pipeline. The check is deny-by-default: if a request’s source is not on the identity’s allow-list, it is rejected before authentication even matters. Because the rule is attached to the identity and enforced centrally, it cannot be skipped by reaching a different endpoint.
Trust the source address only as far as your network terminates it. Behind a proxy or load balancer, derive the client IP from a trusted, sanitized forwarded header — never from a client-settable value an attacker controls. B5 reads the source through the configured trusted-proxy chain for exactly this reason.
3. The strict core under the adaptive shell
This static allow-list is deliberately rigid, and that rigidity is a feature. It is the deny-by-default ground truth that the adaptive identity firewall builds on: geo and ASN rules, threat-intelligence deny feeds, and rate limits add dynamic judgement above the static core, but they never relax it. A request that fails the allow-list is denied regardless of how benign the adaptive signals look. Defense in depth means the strict layer and the adaptive layer both have to pass.
4. Interplay with key-leakage protection
IP binding pairs with key-leakage protection to make a stolen key inert. Key-leakage protection stops sensitive API keys from being used from browsers or otherwise non-allow-listed contexts; IP binding stops them being used from non-allow-listed networks. Together they mean a key that escapes into client-side code, a log, or an attacker’s infrastructure simply stops working — the credential is alive only where you said it could live.
5. The calling convention
Allow-lists are properties of the identity, enforced by the pipeline. Sensitive identities can be required to carry one.
// Deny-by-default network binding, per identity, enforced pipeline-wide
services.AddB5SecurityKit(o => {
o.IpFirewall.Mode = FirewallMode.DenyByDefault;
o.IpFirewall.RequireForKeys = KeySensitivity.High; // high-priv keys MUST be bound
o.IpFirewall.TrustedProxies = ForwardedFrom.EdgeOnly; // derive client IP safely
});
// A service key scoped to the networks it may operate from
var key = serviceKeys.Issue("ledger-sync", allowFrom: "203.0.113.0/24");6. What an attacker actually gets
An attacker who exfiltrates a high-privileged key gets a credential that does nothing from their network: the allow-list rejects them before authentication is even attempted. Combined with key-leakage protection, the same key is also dead from a browser. To use it, the attacker would have to operate from inside an allow-listed range — a far higher bar than simply possessing the secret. The static rule offers no adaptive gray area to talk its way past.
7. Where this lands in an audit
IP binding evidences network access control and restriction of credentials to authorized sources (SOC 2 CC6.1, CC6.6; ISO 27001 A.8.20–A.8.22; CIS Controls v8). It is a concrete, demonstrable answer to “what stops a leaked key from being used by anyone, anywhere?” — and it pairs cleanly with the adaptive-firewall narrative for reviewers who probe defense in depth.
Next: Adaptive Identity Firewall — a strict core, an adaptive shell →