Security Guide · Stage 1 Companion

IP Allowlisting vs. Zero-Day Threats.

A zero-day is a flaw with no patch yet available. IP allowlisting can't fix the flaw — but by controlling who can reach the service at all, it removes the attacker's ability to touch the vulnerable code path in the first place.

Reachability as Control Pre-Auth Exposure Attack-Surface Reduction Exposure Window Defence in Depth
The Core Idea

A vulnerability an attacker cannot reach is a vulnerability they cannot exploit.

The flaw is unknown

By definition, a zero-day is a weakness the vendor hasn't yet found or fixed. You can't sign a rule for a signature nobody has.

There is no patch

Signature and patch-based defences are always a step behind an exploit that predates them. The window between exploitation and a fix is where damage happens.

Reachability is removed

Allowlisting acts at the network layer, before the vulnerable application logic is ever invoked. If an attacker's packets can't arrive, the unknown flaw is never reached.

Allowlisting doesn't patch the bug. It removes the attacker's path to it.

Preconditions of Exploitation

What a remote zero-day actually needs.

Most remotely exploited zero-days share the same first requirement: the attacker has to reach the vulnerable service to deliver anything to it. Network-layer allowlisting intervenes at exactly that first step — before authentication, before request parsing, before the flawed code runs.

Unknown Attacker
the open, hostile internet
Public Internet
IP Allowlist Checkpacket dropped if source is not trusted
Vulnerable Service

The allowlist decides reachability before the request is ever parsed.

Why the ordering matters

  • The check runs on source address, not on request content — so it doesn't depend on recognising the exploit.
  • It applies to pre-authentication flaws, where a broken login page or parser is the target.
  • Mass internet scanning — the way most opportunistic exploitation begins — simply never sees the service.
  • Protection holds the moment the vulnerability is disclosed — you don't have to wait for a vendor fix.
What it assumes

This works for flaws reached over the network from an untrusted source. It says nothing about a zero-day delivered through an already-trusted path — that is a separate problem, covered below.

POSITION IN THE STACK Before the Application

Shrinking the window, not the bug.

A patch closes a vulnerability. An allowlist can't do that — but it changes who is exposed to the vulnerability while it remains unpatched. That difference is the entire value: it collapses the exposure window for the population of attackers who don't already hold a trusted address.

Exposed Service

Reachable by anyone

  • Visible to internet-wide scanning
  • Any source can deliver to the flawed code path
  • Exploitable from disclosure until a patch ships
  • Opportunistic and commodity exploitation apply
The vulnerability and the whole internet meet at the same door.
Allowlisted Service

Reachable by trusted sources only

  • Invisible to untrusted scanning and probes
  • Only allowlisted addresses can reach the code path
  • An attacker must first control a trusted source
  • Mass and opportunistic exploitation is filtered out
The flaw remains — but the set of parties who can reach it is small and known.

This is why allowlisting is described as an attack-surface reduction, not a fix. It doesn't make the software correct; it makes the correctness of that software matter to far fewer people.

Exposure, Compared

The same unpatched flaw, three postures.

Hold the vulnerability constant and vary only the access posture. The bug is identical in every column — what changes is who can get close enough to trigger it.

Against an unpatched zero-day Public Endpoint IP Allowlisted IP + mTLS
Reachable by an unknown attacker Yes No No
Exposed to mass internet scanning Yes No No
Opportunistic / commodity exploitation Exposed Filtered Filtered
Exploit window before a patch exists Full Reduced Reduced
Attacker must first control a trusted source No Yes — a trusted IP Yes — IP + valid cert
Resists a spoofed / borrowed source address Partial Yes

Allowlisting doesn't move a single row of the vulnerability itself — it moves the rows about who can reach it.

What It Neutralises

The classes of attack it takes off the table.

Against a network-reachable zero-day, allowlisting removes several whole categories of threat at once — the ones that depend on being able to reach an exposed service from an arbitrary address.

01 Mass Internet ScanningUntrusted sources can't enumerate or fingerprint a service they can't reach. Discovery
02 Opportunistic ExploitationCommodity, spray-and-pray exploitation of a fresh disclosure never lands on the endpoint. Volume
03 Pre-Auth ReachabilityFlaws in the login page or request parser are gated behind the network check that runs first. Pre-Auth
04 The Exposure WindowProtection applies from disclosure onward — no waiting for a vendor patch to close the gap. Timing
05 Worm & Botnet PropagationSelf-spreading exploitation that hops between exposed hosts finds no open door here. Spread

These are real reductions, not theoretical ones — they remove the most common ways an unpatched flaw is reached at scale. What they do not do is make the service invulnerable, and it's worth being precise about that.

Calibrated Scope

What it does not fix.

Allowlisting is a control over reachability, and that boundary defines its limits honestly. It is a layer, not a cure — and it should be described as reducing attack surface, never as immunity to zero-days.

  • It is not a patch. The vulnerability still exists and still needs remediation when a fix is available.
  • A zero-day delivered from a trusted source — a compromised allowlisted host — still reaches the flaw.
  • It does nothing for client-side or supply-chain zero-days that arrive through content, dependencies or the user's own device.
  • The allowlisted endpoints themselves become the thing to protect — their hygiene now carries the boundary.
The honest claim

IP allowlisting meaningfully reduces exposure to network-reachable zero-days by shrinking who can reach the vulnerable service and collapsing the exposure window. It is one layer in a staged model — not a substitute for patching, monitoring, or the controls above and below it.

This is exactly why the entityOS approach is staged: each layer narrows the reachable surface further, so no single control has to carry the whole burden.

The Staged Model

Reachability, narrowed stage by stage.

STAGE 01

IP Allowlisting

Network-layer control of who can reach the service. Removes untrusted reachability — and with it, most opportunistic zero-day exposure.

source address → allow / drop
STAGE 02

mTLS + X.509

Cryptographic per-connection identity. A trusted address alone is no longer enough — the caller must also present a valid certificate.

identity → verified per connection
STAGE 03

KERI / ACDC

Self-sovereign identity for credential-level trust — provenance and verifiable credentials underneath the transport.

credential → provenance-backed

A zero-day is only as dangerous as the set of attackers who can reach it. Allowlisting shrinks that set to a small, known group — and each further stage shrinks it again.

The flaw isn't fixed by any of this. The reachability of the flaw is what the closed-internet model steadily takes away.