Can I use Enclave IP ranges as a compensating control?¶

Some applications allow administrators to restrict access by source IP address or source CIDR range. This is common for databases, internal services, SaaS administration consoles, and network appliances.

Customers sometimes ask whether they should reduce the Enclave virtual network range from the default 100.64.0.0/10 to a smaller range, such as 100.64.0.0/24, then use that smaller range as a compensating control in case another Enclave security control fails.

The short answer is no. If an auditor asks for a compensating control against an Enclave tenant-isolation failure, describe the independent application-layer controls rather than relying on CIDR size.

Source IP allowlisting can still be useful for operational hygiene, audit hygiene, compatibility, or reducing accidental exposure, but it should not be treated as a replacement for identity, policy, or application-layer security.

The distinction is important in regulated environments: a smaller range may help satisfy an administrative or audit expectation, but that does not make source IP the right control to carry the security argument.

The customer question¶

A typical version of the question is:

Our application accepts connections only from approved source IP ranges. Our Enclave systems use addresses from 100.64.0.0/10 by default, which is much larger than the number of devices in our organisation. Can we reduce the Enclave IP range and use that smaller CIDR allowlist as a compensating control for a platform or tenant-isolation failure?

This is a reasonable question, especially in regulated environments where each security control may need to be assessed as if other controls have failed.

Enclave uses identity, not IP addresses, for access control¶

Enclave's security model is based on device identity, enrolment, policy, and mutually authenticated encrypted connectivity between peers. The Enclave virtual IP address is used for addressing and routing. It is not the primary trust primitive and should not be treated as a non-forgeable identity boundary.

Restricting an application to a smaller Enclave CIDR range does not meaningfully constrain who can reach that application through Enclave if the assumed failure mode is that an unauthorised device has already been admitted to the overlay. In that scenario, the relevant boundary has already moved past IP routing and into peer identity, policy, and application-layer authorisation.

In other words, if a threat model assumes that Enclave has authorised the wrong peer, narrowing the source CIDR is not a strong compensating control. The stronger control is to require an independent condition that the mis-admitted peer cannot satisfy.

Why source IP is not enough¶

IP allowlisting can look like an independent containment boundary because it is enforced by the destination service. However, for Enclave traffic, source IP is not equivalent to device identity.

Enclave policy decides which enrolled systems are allowed to communicate. The virtual IP address helps those systems route traffic once communication is permitted. A smaller CIDR range may make firewall rules easier to read, but it does not replace identity-based access control.

The IP address can be an audit attribute, but it should not be treated as the identity.

This distinction matters most when evaluating hypothetical platform failure modes. If the concern is a bug, misconfiguration, or tenant-contamination event that allows the wrong device to participate, the compensating control should be one that remains independent of Enclave participation.

Better compensating controls¶

For sensitive services, use controls that the destination application or service can verify independently of Enclave source IP.

Good examples include:

Mutual TLS using a customer-controlled certificate authority.
Per-user or per-service database credentials.
Least-privilege roles and permissions.
Application-layer authorisation.
Strong secret and credential issuance processes.
Audit logging at the application, database, and operating system layers.
Alerts for unexpected accounts, roles, source hosts, or access patterns.

These controls continue to add value even if an unexpected device can route to the service, because the device must still satisfy separate authentication and authorisation requirements.

PostgreSQL example¶

PostgreSQL's pg_hba.conf can restrict access by source address. It can also enforce stronger controls, including client certificate authentication, database users, and role-based permissions.

For an Enclave-protected PostgreSQL service, source CIDR restrictions can be one layer of policy hygiene, but they should not be the control used to compensate for an assumed Enclave platform failure. A stronger pattern is to combine Enclave policy with PostgreSQL controls such as:

Client certificate authentication tied to a CA you control.
Database credentials issued only to approved users or services.
Least-privilege database roles.
Logging and alerting for unexpected authentication attempts.

This makes PostgreSQL enforce its own independent access decision after Enclave has provided private network reachability.

When smaller ranges still help¶

There are valid operational reasons to use a smaller or different virtual network range, including avoiding address overlap, simplifying firewall rules, or meeting an application compatibility requirement.

Those are operational or audit-hygiene reasons. They can make the environment easier to explain and operate, but they do not change where the security boundary sits.

Last updated May 22, 2026