entityOS Security — Practical IT Guide

Choosing IP restriction or mTLS for your organisation.

A working guide for IT teams. How to pick the right access mechanism for each user type, what to prepare before you start, and how to roll it out without locking anyone out.

Start the Decision Rollout Playbooks
Scroll

The Two Options

Two mechanisms. Pick per user.

Both protect the same restricted surface — entityos.cloud. They are independent, not sequential. You can run both at once.

Option A — IP Restriction

Allowlist the network location

The device registers its public IP address. That IP is synced to the restricted firewall's IP Set. Any connection from that IP is admitted — no certificate, no client software.

  • → Best for fixed offices and static IP ranges
  • → Zero per-device setup once the IP is registered
  • → Trust is tied to the location, not the user
  • → Breaks if the ISP changes the IP — re-register
Option B — mTLS / X.509

Issue a certificate to the device

The device registers a certificate signing request. entityOS CA signs it. The device presents the certificate on every connection. The firewall validates it — the IP can be anything.

  • → Best for laptops and roaming or remote users
  • → Trust travels with the device, not the network
  • → Per-device install + rotation to manage
  • → A lost device is handled by revoking one cert

Step 1 — Decide

A three-question decision path.

Run these questions per user group — not for the whole organisation at once. Most organisations land on a mix.

Question 1
Does this user group always connect from a known, fixed network?
Yes — office or static IP
Lean toward IP Restriction
Office desktops behind a static public IP, or a site with a fixed ISP range. Continue to Question 2 to confirm.
No — they roam
Lean toward mTLS
Laptops used from home, cafes, or client sites. The IP changes constantly, so location-based trust will not work. Skip to Question 3.
Question 2
Is that fixed IP genuinely stable, or does the ISP rotate it?
Confirmed static
IP Restriction is sufficient
A business-grade static IP or a documented CIDR range. Register it once and the group needs no client-side change.
Dynamic / unknown
Use mTLS instead
A dynamic residential or consumer IP will silently change and lock the group out. Treat them as roaming and issue certificates.
Question 3
Can you deploy and manage certificates on these devices?
Yes — managed fleet
mTLS is the right fit
Devices are enrolled in an MDM, Intune, or GPO that can push the certificate and the registration helper. Rotation can be automated.
No — unmanaged devices
Reconsider scope
If a device cannot hold a managed certificate, it should not reach the restricted zone. Provide a managed device, or keep that user in the open zone only.

Step 2 — Map Your Users

A recommendation for every user type.

The common patterns IT teams encounter, with the mechanism that fits each. Use it as a starting template, then adjust to your organisation's groups.

User / device type Network pattern Recommended Why
Office desktops Fixed corporate LAN, static public IP IP Restriction Location never changes. Register the office IP once; no per-device work.
Branch / site offices Each site on its own static range IP Restriction Register each site's CIDR range. Adding a site is one IP entry.
Remote-work laptops Home, cafe, client site — dynamic IP mTLS IP is unpredictable. A device certificate travels with the laptop.
Travelling / field staff Mobile networks, hotspots, hotels mTLS No fixed location at all. Certificate identity is the only workable basis.
Servers & service accounts Fixed data-centre / cloud IP IP + mTLS Non-interactive and high-value. Pin both the IP and a service certificate.
Admin / privileged access Any — high sensitivity IP + mTLS Require both checks so a single stolen credential cannot grant entry.

Step 3 — Roll It Out

Three rollout playbooks.

Pick the playbook that matches your decision. Each is sequenced so no user is locked out mid-rollout — the restricted firewall stays permissive until the last step.

Playbook A

Deploy IP Restriction

For office and static-IP user groups. No client-side changes — the work is registration and firewall configuration.

  1. Inventory IPs. Confirm each office or site's public IP or CIDR range with the network owner, in writing.
  2. Register IPs. Submit each IP and the pre-exchanged security code through register.entityos.io.
  3. Confirm sync. Verify each IP has propagated into the restricted firewall's IP Set.
  4. Test in parallel. Connect from a registered IP and confirm access while the firewall is still open.
  5. Close the zone. Remove the 0.0.0.0/0 inbound rule so only registered IPs are admitted.
  6. Validate. Confirm registered IPs pass and an unregistered IP is dropped silently.
Playbook B

Deploy mTLS / X.509

For roaming and remote user groups. The work is certificate issuance, distribution, and lifecycle.

  1. Stand up the CA. Provision entityOS CA (AWS Private CA or entityOS-managed) as the signing authority.
  2. Issue certificates. Each device submits a CSR plus its security code; entityOS CA signs and returns the X.509 cert.
  3. Distribute. Push the signed cert to each device via MDM, Intune, or GPO into the system trust store.
  4. Enable the rule. Add the X.509 Certs rule on the restricted firewall and enforce mutual TLS at the API gateway.
  5. Pilot then expand. Validate one device end-to-end, then roll the rest in batches.
  6. Schedule rotation. Set a renewal cadence and a revocation path for lost or retired devices.
Playbook C — Combined

Run IP Restriction and mTLS together

For a mixed organisation, or for high-sensitivity groups that need both checks. The two rules are independent — your policy decides whether a connection must pass one, the other, or both.

  1. Segment first. Use the matrix above to assign each user group to IP-only, mTLS-only, or both.
  2. Run Playbook A and Playbook B in parallel. They share one registration surface and one CA — there is no ordering dependency between them.
  3. Set the policy per group. For high-sensitivity groups, require IP Set and X.509 to pass for the same connection.
  4. Verify each path. Test an office desktop (IP passes), a remote laptop (cert passes), and a privileged session (both required).
  5. Close the zone last. Only remove the open inbound rule once every group has a verified working path.

Before You Start

Prerequisites checklist.

Confirm each of these is in place before touching the restricted firewall. Missing one is the most common cause of a stalled rollout.

Registration surface is live
register.entityos.io is reachable from the open zone and accepts IP submissions and CSRs. This is the controlled onramp for both mechanisms.
Both
Security codes are issued
Every device or site has a pre-exchanged unique security code. This is what prevents unauthenticated bulk registration — issue codes through your normal onboarding channel.
Both
Public IPs are documented
For any IP-restricted group, the office or site public IP — or CIDR range — is confirmed in writing with the network owner and known to be static.
IP Restriction
Device management is in place
For any mTLS group, an MDM, Intune, or GPO can push the certificate into the device trust store and run the registration helper without per-user manual steps.
mTLS

Step 4 — Operate

Keeping it running.

Access control is not a one-time project. These are the recurring tasks that keep both mechanisms healthy after go-live.

IP Restriction — ongoing

  • Re-register when an ISP changes an office IP
  • Add a new site's range as part of site setup
  • Remove ranges for closed or relocated offices
  • Review the IP Set quarterly against the office list

mTLS — ongoing

  • Renew certificates before expiry on a set cadence
  • Revoke immediately on a lost or stolen device
  • Issue a cert as part of device onboarding
  • Revoke on offboarding before the device is wiped

Watch Out For

Common pitfalls — and the fix.

The mistakes that most often disrupt an IP or mTLS rollout. Each is avoidable with one preventive step.

Treating a dynamic IP as static
A residential or consumer connection looks fixed for weeks, then the ISP rotates it and the whole group is locked out without warning.
Fix — confirm a business static IP in writing, or default the group to mTLS.
No certificate rotation plan
Certificates issued without a renewal schedule all expire around the same date — and a fleet-wide outage arrives with no warning.
Fix — set the renewal cadence and revocation path before the first cert is issued.
Forcing one mechanism on everyone
Mandating mTLS for office desktops adds needless overhead; mandating IP restriction for roaming laptops simply will not work.
Fix — assign the mechanism per user group using the matrix, not org-wide.
Certificates that outlive the device
A laptop is wiped or retired but its certificate is never revoked, leaving a valid credential unaccounted for.
Fix — make certificate revocation a required step in device offboarding.

In Short

Match the mechanism to the access pattern.

IP restriction for fixed locations. mTLS for roaming devices. Both where the data warrants it. Decide per user group, prepare the prerequisites, test before you close the zone.

The two mechanisms are independent — not sequential. You do not roll out one before the other. A single organisation runs office desktops on IP allowlisting and roaming laptops on mTLS certificates at the same time, against the same restricted firewall — and requires both for its most sensitive groups. The combination is decided by each group's access pattern, not a mandated order.