Explainer · Organisational Continuity

What IP allowlisting does and doesn't do.

A plain-language guide for organisations using entityOS.cloud. Stage 1 of the entityOS closed-internet model reduces who can reach you. It is a real risk reduction — but it is a statistical one, and it is worth being precise about what it buys.

Stage 1 Likelihood × Impact Location ≠ Identity Honest Caveats

What It Changes

It shrinks the probability, not the impact.

Risk is usually expressed as likelihood multiplied by impact. Stage 1 works on the first term only. Once your entityOS space is reachable solely from addresses you have registered, the overwhelming majority of opportunistic Internet traffic never arrives — it simply has nowhere to connect.

Reduced by Stage 1 Likelihood Fewer parties can attempt anything at all

Unchanged by Stage 1 Impact What a successful attacker could still do

What it removes

Automated scanners probing for anything that answers.
Credential stuffing — replaying leaked passwords at scale.
Mass exploitation of a newly published vulnerability, where speed and breadth are the attacker’s whole advantage.
Background noise in logs, so genuine anomalies are easier to see.

What still gets through

Anyone connecting from inside an allowed range — a shared office network, a partner, a contractor on your VPN.
An attacker who has compromised a host that sits inside an allowed range.
A determined, targeted adversary who works out where your traffic comes from and positions themselves there.

Why the second column exists: an IP address is a location, not an identity. The allowlist knows where a connection came from. It has no idea who is sitting behind it.

Why That Distinction Matters

Location filter first. Identity control second.

That limitation is exactly what makes IP allowlisting a clean first stage. It is cheap, fast to deploy, and removes most of the noise — which is what you want from a coarse filter. It is not what you want to rely on as your only control, which is why the model has a Stage 2.

Stage 1 · Available now

IP allowlisting — the coarse filter

Answers: “Is this connection coming from somewhere we expect?”
Enforced at the network edge before any application code runs.
Registered by your organisation via ip.register.entityos.io.
Trusts the place, and everything currently in it.

Reduces the number of parties that can reach you. Does not verify any of them.

Stage 2 · Coming soon

mTLS + X.509 — the actual control

Answers: “Can this connection prove, cryptographically, who it is?”
Each client presents a certificate issued to it; the connection fails without one.
Works wherever the client is — office, home, hotel, cloud.
Trusts the identity, not the network it arrived on.

Proves who is connecting. Stage 1 keeps the crowd out; Stage 2 checks the ID of whoever remains.

The two are layered, not alternatives. Running Stage 1 today is the right move. Describing Stage 1 as if it were Stage 2 is the mistake to avoid.

Both stages are additive to the existing best-practice network firewall and application protection already in place on entityOS.cloud — application protection including MFA (TOTP), Passkeys and IP restrictions. They sit with these controls; they do not replace them.

The Caveats

Say these out loud, before someone else does.

If a risk register, an insurer, or an auditor is told “we have reduced our risk with IP allowlisting” without the following qualifications, expect the claim to be challenged. Each caveat also has a direct continuity consequence.

CAVEAT 01 · OVER-ADMITS

Shared addresses let in more than you think

Many organisations sit behind a single shared address (NAT) or use cloud services whose outbound ranges are shared with thousands of other customers. Allowing that range allows everyone else behind it too.

Continuity consequenceAllowing a broad cloud egress range to “make things work” quietly widens the door. Prefer narrow, organisation-controlled addresses — ideally a single /32 per site.

CAVEAT 02 · UNDER-ADMITS

Changing addresses lock out legitimate people

Home broadband, mobile connections and many small-office links change address without warning. When they do, the people using them are locked out until the allowlist is updated — usually at the least convenient moment.

Continuity consequenceThis is operational drag, and it needs an owner. Who updates the allowlist, how quickly, and from where, when the office link fails on a public holiday?

CAVEAT 03 · NO HELP AFTER COMPROMISE

A compromised trusted host is fully trusted

If a laptop or server inside an allowed range is taken over — by phishing, malware, or a stolen session — the allowlist sees a normal connection from a normal place and lets it through. It provides no protection at all at that point.

Continuity consequenceEndpoint hygiene, MFA and incident response still carry the load once someone is inside. Stage 2 is what starts to close this gap.

For the Continuity Plan

Four things a manager should own.

None of these are technical tasks. They are decisions and responsibilities that need a name against them so that Stage 1 improves resilience rather than becoming a new way to lose access.

01 Know your registered addressesKeep a current list of what is allowed, why, and who it belongs to. Review it on a schedule, not only when something breaks. Inventory

02 Have a lock-out recovery pathIf your primary address changes or your VPN fails, how does an authorised person re-register? A VPN that is the only route is a single point of failure, not a continuity control. Recovery

03 Keep the rest of the controlsMFA, patched endpoints and a practised incident response are what protect you once a trusted host is compromised. Stage 1 does not replace any of them. Depth

04 Plan for Stage 2Certificate-based identity removes the dependence on where people are. Decide now who will hold certificates and how they will be issued and revoked, so the move is a step and not a project. Identity

Described this way, Stage 1 is defensible in front of a board, an insurer or an auditor: a low-cost, high-yield reduction in exposure, with known limits and a named path to the stronger control.

In One Breath

What to say when asked.

“We have restricted access to our entityOS space to addresses we control. That removes almost all opportunistic attack traffic — it reduces the likelihood of an incident, not its impact.

It does not stop a determined attacker, it admits anyone behind a shared address we allow, and it cannot help once one of our own machines is compromised.

That is why it is Stage 1. Stage 2 adds cryptographic identity, so we prove who is connecting rather than just where from.”

If you can say all three sentences comfortably, you understand the control well enough to be responsible for it.

Continuity Hub Stage 1 — IP Allowlisting Stage 2 — mTLS