Security Implementation
A concrete walkthrough of how IP allowlisting and mTLS are bootstrapped and enforced on the entityOS.cloud platform — from introspecting usage logs to issuing browser-bound X.509 certificates.
Network boundary control via AWS WAF IPSet rules — automatically seeded from real usage patterns and managed by space administrators with a self-service recovery path.
Extract real caller IP addresses from entityOS.cloud usage logs
Read existing Network Access Rules from the entityOS security system
Auto-populate the AWS WAF IPSet ready for rule attachment
entityOS.cloud continuously logs all API requests. During bootstrapping, these logs are analysed to extract the set of IP addresses that have made legitimate calls for each space. This builds a real-world picture of who is accessing the platform — rather than relying solely on manually declared addresses.
Any IP addresses already declared by space administrators via SETUP_USER_NETWORK_ACCESS_MANAGE Network Access Rules are merged into the set. This ensures that both observed traffic and explicitly declared addresses are included — preventing legitimate users from being locked out during the transition.
The combined IP address set is written into a dedicated IPSet on the AWS Web Application Firewall. The IPSet is pre-populated and staged — it exists in AWS but is not yet attached to any blocking rule. This allows partners to review and validate the set before enforcement begins.
Once partners confirm readiness, the pre-populated IPSet is attached to an AWS WAF ALLOW rule. All other IP addresses are blocked by default — the WAF default action becomes BLOCK. From this point, only addresses in the IPSet can reach entityOS.cloud services for that space.
Space administrators can add new IP addresses for their users at any time using the SETUP_USER_NETWORK_ACCESS_MANAGE permission in entityOS.cloud. Each new Network Access Rule is automatically synchronised to the WAF IPSet — no manual AWS intervention required. Administrators manage their users' access from within the entityOS console.
If a space administrator's own IP address changes and they become locked out, they have a recovery path that does not require contacting support. Using a unique security code issued during onboarding, the administrator can register their new IP address at the dedicated recovery portal.
The entityOS.io Certificate Authority issues browser-bound X.509 certificates to space administrators and their users — enforced at the AWS WAF layer, with a self-service registration portal backed by a unique onboarding security code.
Dedicated private AWS Certificate Authority issues all X.509 certs
CA is bound to the AWS WAF — only valid certs pass the mutual TLS check
Space admins generate and submit browser-bound certificates via portal
entityOS.cloud runs a dedicated private X.509 Certificate Authority on AWS Private CA — the entityOS.io CA. This CA is the root of trust for all mTLS enforcement on the platform. It issues certificates exclusively to verified entityOS.cloud users — no external certificates are accepted.
The entityOS.io CA is configured as the mutual TLS trust anchor for the entityOS.cloud AWS WAF. This means the WAF enforces certificate verification on every inbound request — connections that do not present a certificate signed by the entityOS.io CA are rejected at the network layer, before any application logic is reached.
Space administrators register their browser certificate at the dedicated portal. The portal generates a certificate, stores it in the administrator's browser, and — using the unique security code issued during onboarding — submits it for signing. The entityOS.io CA signs the certificate, associates it with the administrator's user account, and from that point all their requests to entityOS.cloud carry a WAF-recognised certificate.
Once space administrators have their certificates in place, they initiate rollout to their users. Each user follows the same self-service registration process at cert.register.entityos.io. The certificate is generated, stored in their browser's certificate store, and submitted for signing against the administrator's space. The entityOS.io CA signs and associates it — the user is then recognised by the AWS WAF on every subsequent request.
Certificates are stored in the browser's native certificate store — not in application memory, local storage, or as a cookie. The browser presents the certificate automatically with every HTTPS request to entityOS.cloud. No application-level token management is required. The mTLS handshake occurs at the TLS layer before the HTTP request is processed.
With both stages active, every request to entityOS.cloud must pass two independent checks at the AWS WAF: the source IP must be in the space's allowlist, and the request must carry a valid X.509 certificate signed by the entityOS.io CA. Either control alone would block most attackers — together they require an adversary to possess both network position and a CA-signed credential simultaneously.
Deployed on entityOS.cloud
Both stages run in production on entityOS.cloud today — enforced at the AWS WAF layer before any application code is reached.
Stage 1 ensures that only IP addresses your space has authorised can even reach entityOS.cloud services. Every other address on the internet is silently dropped at the network edge.
Stage 2 ensures that even traffic from an allowlisted IP must carry a browser-bound X.509 certificate signed by the entityOS.io CA. A correct IP without a valid certificate is rejected. A valid certificate from an unlisted IP is also rejected.
The result: access to your entityOS.cloud space requires both network position and cryptographic identity — two independent controls that an attacker must defeat simultaneously.