Substituting IP address evaluation with hardware-rooted sovereign zero trust

The need for trustworthy networking, reliable cloud access, and compliance with digital sovereignty requirements has increased substantially in recent years. These demands have been generally addressed by fragile, costly, and outdated models based on IP address evaluation. These requirements must also be considered within the stark geopolitical reality of data sovereignty, where national and regional laws increasingly restrict where data must reside and who can access it.

We believe it is time to provide enhanced, identity-based mechanisms to satisfy these requirements and to address use cases that have seen their development limited by current practices. The end solution must address the concerns of development, security, and operations (DevSecOps) practitioners navigating sensitive customer data in financial services and healthcare, edge computing specialists dealing with securing massively distributed, physically insecure infrastructures, secure access service edge (SASE), and zero trust network access (ZTNA) security engineers . Our approach replaces permeable network perimeters with variable, attested, and stateful identities even when they do not have direct control of endpoint devices. As a demonstration, this article focuses on geospatial attributes, as a general application of the general pattern that can extend to other related cases.

The problem: The IP address bottleneck

The legacy security model, built on IP address evaluation, creates a triple challenge:

Costly and brittle: It forces significant investments in network appliances (firewalls, load balancers) and generates significant operational overhead. With dynamic IP addresses or name-to-address mappings in DNS constantly shifting, using IP based rules or logic often falls out of sync with underlying infrastructure.

Slows innovation: Every infrastructure change, such as new service deployments, demands manual firewall updates, grinding development to a halt.

Vulnerable: IP-based security offers a weak perimeter, susceptible to lateral movement once an attacker breaches the initial defences.

Figure 1: A core aspect of the problem: once an attack has access to a the network through a compromised workload, network based identities often allow access to the underlying sovereign data

IP addresses can be spoofed (for example, by a VPN), rendering them unreliable for verifying physical location compliance. This fails to meet strict data residency requirements (such as the ones in force in the EU) that demand sensitive data be processed only within specific geographic borders.

This article proposes a paradigm shift, moving beyond using the IP address as reliable identification data, to hardware-rooted identity. We outline here a modern, two-part solution to achieve a truly sovereign and automated zero trust posture, leveraging open source technologies.

Stage 1: Workload identity for automation and agility (SPIFFE/SPIRE)

The first, transformative step is to adopt SPIFFE (secure production identity framework for everyone) and SPIRE (the SPIFFE runtime environment). This isn't merely a security tool, but an automation and agility platform. With it, we transition from vulnerable IP-based security to a cryptographic identity model where every workload possesses a unique, verifiable identity.

If you are unfamiliar with SPIFFE or SPIRE, you can check this primer (https://spiffe.io/).

Figure 2: An example of real world impact adopting a Sovereign Zero Trust model for our hypothetical European financial service.

We show how this works with a thought exercise: Imagine a major European bank launching an AI fraud detection microservice on edge clusters across its regional data centers. This service requires privileged access to core customer transaction data, making its security and compliance paramount under General Data Protection Regulation (GDPR) and any national transposition of the law.

Each service component upon launch would immediately attest its own identity using their SPIFFE/SPIRE IDs, provided by cryptographic hardware information. This ensures that only cryptographically verified machines can participate in the deployment. CI/CD pipelines utilize the fraud detection microservice, triggered by an approved update, allowing transition from static automation secrets to securely exchanged SPIFFE-verifiable identity documents (SVIDs). Platform components (such as the application code, test tools, and scanners) mutually authenticate using their respective SVIDs with mutual transport-layer security (mTLS) during deployment.

Security benefits

• Zero trust micro-segmentation: Every workload's identity is cryptographically verified before communication. No more implicit trust based on network location.
• Elimination of shared secrets: SPIFFE/SPIRE replaces manually managed secrets like API keys or passwords with unique short-lived workload identities and credentials that are automatically rotated. This drastically reduces one of the greatest risks enterprises face: credential leaks and compromise.
• Reduced attack surface: SVIDs are ephemeral, and automatically expire. This means a stolen identity can only be useful for a very short period, thwarting advanced persistent threats (APT). Credential strength and policies can be centrally managed.

Cost savings and business enablement

• Automated identity lifecycle: Significant savings from reducing manual effort in managing IP whitelists and firewall rules. Engineering and security teams are freed up from tedious, error-prone tasks.
• Reduced network hardware costs: Security is extended up to the application layer. This allows for a significant reduction in (or even elimination of) expensive network appliances like traditional firewalls and load balancers.
• Faster time-to-market: Development teams deploy new services faster and more securely, no longer bottlenecked by manual security configurations.

Stage 2: Enhanced security with attestation and geofencing

While Stage 1 brought in security and automation, there are still challenges:

• Geofencing: IP addresses and associated networks are often used as a proxy for geographic location.
• Compromised host risk: Workloads could run on disallowed hosts or hosts running in or attached to disallowed infrastructure.
• Credential risk: Replayable cluster bootstrap tokens that can move from allowed to unallowed infrastructure.

Figure 3: Traditional network based security controls can be spoofed, for example by a VPN or a compromised workload already present on the network

In Stage 2, we move beyond simple software identity to a hardware-rooted, geolocation-context aware security posture by integrating already-proven TPM-based attestation. This is where we unlock true competitive advantage and regulatory compliance by implementing verifiable geofencing.

The use of TPM allows us to bind a workload with the underlying platform. This underlying platform possesses attributes we want to test against (for example, a geographic location). We can also bind other platform aspects including attached devices such as our geolocation data source, a local GPS receiver or a CAMARA location API. This binding is encoded as an attestation from the TPM of the host platform and unifies these identities, by providing verifiable evidence of the geospatial coordinates corresponding to the platform. The bound devices can produce these coordinates from third-party location services, as in the case of GPS, and even allow a third party to assess the actual location of the device, by means of the CAMARA location APIs.

A verifiable geofencing capability can form a cornerstone for regulatory compliance, particularly for strict European laws. It satisfies mandates like the requirement for a major European bank to prove sensitive customer data (DNI/NIE numbers, account details, and so on) is processed exclusively within data centers physically located in, for example, the European economic area (EEA).

Figure 4: Real-world impact: Sovereign zero trust in an example financial services

For our example fraud microservice rollout, stage 2 is critical. A modern digital sovereignty policy demands that administrator actions and deployment systems originate physically from within the organization's country.

• Human authorization: A rollout starts as a DevSecOps administrator using an identity and access management (IAM) platform enhanced with TPM-based attestation and a verifiable geofence to prove that the administrator is using an approved device from an approved geolocation. Using this identity, the administrator now approves a code update.
• Context-aware policy enforcement: The CI/CD platform components, which have the approved code, use a high-assurance, TPM-based SVID that includes a verifiable geolocation claim during code execution for fetching secrets from a vault. The vault, using its integrated policy engine, for example the open policy agent (OPA), enforces the following policies:
  • Allow production secrets (passwords, keys, and so on) if the SVID belongs to fraud-microservice, and the host is a trusted host, and the host is in a trusted geolocation (for example, within the country).
  • Deny all secret access if the SVID's integrity claim fails, or the geolocation is unauthorized (for example, outside the country, violating data residency requirements).

Security benefits

• Hardware-based root of trust: TPM attestation provides a tamper-proof identity that cannot be spoofed, protecting against sophisticated attacks like rootkits. Identity is tied directly to physical hardware, guaranteeing authenticity.
• Context-aware enforcement for sovereignty: Verifiable geofencing enforces policies based on physical location - essential for data residency and compliance with national laws like the GDPR. If a workload moves to an unauthorized location, its identity and access rights are automatically revoked.

Cost savings and business enablement

• Operational savings: By unifying the workload and host integrity lifecycles, you eliminate the need for separate security tools and manual processes, resulting in cost savings.
• Risk reduction: Unified identity for host and workload simplifies problem troubleshooting thus reducing mean time to respond, and reducing risk.
• New business opportunities: This enhanced, cryptographically proven security posture allows organizations to confidently pursue new business in highly regulated industries. By demonstrating verifiable compliance (for example, proving data is always processed in a compliant location), it becomes a significant competitive differentiator.

Conclusion: A unified blueprint for sovereign trust

This advanced capability in stage 2, going beyond current SPIFFE/SPIRE standards, is being developed as a joint hybrid cloud proof of concept (PoC). This hardware-rooted workload attestation and geofencing PoC is powered by a simulated mobile network, which provides a spoof-resistant geolocation, proven linux and Kubernetes foundations, and key, open source modifications to SPIFFE/SPIRE, and Keylime and other open source projects. Beyond stage 2, supply chain security is another use case where unified identity introduces potential opportunities to define new SLSA levels.

The unified identity idea is also directly influencing industry collaboration efforts like the Internet Engineering Task Force (IETF) draft on Verifiable Geofencing and the Linux Foundation's AegisEdgeAI project. We expect these standards and projects to enable development of these capabilities, and to tackle new use cases and applications for verifiable geolocation and residency

This end-to-end lifecycle represents a unified blueprint for securing privileged access, whether it's for a human or an automated machine. It moves beyond managing static secrets and into a world where trust is continuously verified with a hardware root.

This article is the authors' independent work and reflects their personal views. It is based on publicly available open standards and open source technologies. The work explores vendor-neutral standards for verifiable geolocation and hardware-anchored trust to support sovereign, interoperable security architectures. References to standards drafts, projects, companies, or products are provided for informational purposes only and do not imply endorsement or formal affiliation. All trademarks are the property of their respective owners. No confidential or proprietary information from any employer is included; the discussion relies on public materials and open source code under their respective licenses. Affiliations are listed for identification only; the views expressed do not represent those of any employer or organization. Nothing herein represents an official position of any standards body or project (for example, IETF drafts, AegisSovereignAI).