Two zones. Two firewalls. One certificate authority. IP restriction and mTLS certificate identity can be deployed independently or combined — matched to the access pattern of each user type in your organisation.
The Architecture
The intentionally public registration surface. A user agent visits here to submit their IP and certificate request. No identity required to reach this zone — it is the controlled onramp.
The protected application surface. The restricted firewall supports three rule types — Standard Rules, IP Set, and X.509 Certs — which can be enabled independently or together depending on the access pattern of the user or device.
Architecture Diagram
Every component and flow from User Agent to Certificate Authority, mapped from the entityOS security architecture.
Implementation Mechanisms
These are two independent mechanisms. Each can be deployed on its own. The right combination depends on the access pattern of the user or device, not a mandated sequence.
The user agent registers its IP via register.entityos.io. The IP is processed and synced to the restricted firewall's IP Set. Any connection from that IP is admitted — no certificate required. Best suited to fixed, predictable network locations.
The user agent registers its CSR via register.entityos.io. entityOS CA signs the certificate. The client presents it on every connection via mTLS. The restricted firewall validates the cert — no fixed IP required. Best suited to mobile or roaming users.
Both mechanisms can be active simultaneously on the same restricted firewall. The IP Set and the X.509 Certs rule are independent checks — a connection can be required to pass one, the other, or both, depending on your policy. This means a single organisation can run mixed access patterns in parallel: office desktops on IP allowlisting, and laptops on mTLS certificates, all terminating at the same entityos.cloud endpoint.
System Components
Six components, directly from the architecture diagram. Each has a zone, a function, and a dependency.
The public registration endpoint. Intentionally open — no cert required to reach it. Validates the pre-exchanged security code before passing submissions downstream.
The open zone's backend. Persists all registration submissions, then routes them: IPs go to the IP Rules engine, cert requests go to entityOS CA.
The primary gate of entityos.cloud. Three simultaneous rule types — all must pass. Anonymous traffic is dropped before any application code executes.
Receives processed IP addresses from the open zone. Sync IPs propagates them to the restricted firewall's IP Set in near real time — keeping both zones coordinated.
The certificate authority for the entire system. Signs X.509 certificates on request. Feeds signed certs back to the client and registers them with the firewall's cert rule.
The application layer — only reachable after the firewall passes both the IP Set and X.509 checks. Contains authentication logic and all protected objects and files.
Registration Flow
Five sequential steps. Two parallel outputs (IP + cert). One verified identity.
The Model
IP restriction for fixed locations. mTLS for roaming devices. Both for maximum assurance. One registration surface, one certificate authority, one restricted firewall — configured to fit your organisation's real-world access patterns.