AI has sped up both sides of the network. Attackers find and exploit vulnerabilities faster than ever, and the business needs to create, change and retire trusted connections faster than ever too. The architecture most enterprises run on was not designed for either.
That is the argument at the center of a new article by Philip Griffiths, NetFoundry’s Head of Strategic Sales, published on the Cloud Security Alliance blog: Identity-Defined Reachability: Reducing Exposure and Connectivity Friction in an Age of Machine-Speed Attack. The piece previews a forthcoming CSA paper and introduces a model the industry will be hearing a lot more about.
The problem: three control systems that never quite agree
Think about any trusted relationship in your environment. A supplier’s engineer needs a diagnostic service. An application needs a database. An AI agent needs an approved tool.
Today that one relationship is governed by three separate systems. Identity and access policy decides who has authority. Network controls decide what is reachable. Application controls decide what operations are permitted. Those three states are rarely in sync, so a service can be reachable before anyone is authorized to use it, and stay reachable long after that authority has ended.
The timing matters. Philip cites Verizon’s 2026 Data Breach Investigations Report: exploitation is now the leading initial-access vector at 31% of breaches, and median full remediation of critical known-exploited vulnerabilities takes 43 days. Exploitation can begin within hours of disclosure. As he puts it, “Even a rejected request can expose a reachable component’s listener or parser to attacker-controlled traffic.”
The “connectivity tax”
In connect-first environments, authority has to be translated into addresses, routes, firewall rules and exceptions, then kept aligned by hand as identities and infrastructure change. Philip calls that recurring cost a connectivity tax. It slows modernization, and every manual translation is another chance for intended access and actual access to drift apart.
The shift: reachability as an output of authorization
Identity-Defined Reachability (IDR) reverses the dependency. Instead of connecting first and authorizing later, a path to a protected service is absent by default. It exists only while verified caller identity, verified service authority, policy and context all support that specific relationship.
Two points stand out:
- A valid identity is not enough. Authority can be scoped to a task or session and end while the identity itself remains valid.
- When authority ends, the path goes away. In Philip’s words: “no standing reachability outside currently authorised relationships.”
Each identity-to-service relationship becomes the single unit for authority, reachability, enforcement and observation. Existing underlay networks stay in place; policy decides which relationships become usable on top of them.
Built on the Zero Trust work you already know
IDR is not a rip-and-replace idea. Philip grounds it in CSA’s Software-Defined Perimeter and Zero Trust Microsegmentation guidance, NIST SP 800-207 and 800-207A, and the CISA Zero Trust Maturity Model v2. It also draws on emerging standards such as SPIFFE for workload identity, AuthZEN for authorization decisions, and Shared Signals/CAEP for continuous reassessment.
Where it applies
The article walks through four use cases:
- Agentic AI: an agent reaches an internal service only for the duration of its assigned task.
- Enterprise microsegmentation: policy tied to the relationship, not to IP addresses, so changes don’t trigger endless reconfiguration.
- Operational technology: better protection around legacy equipment without waiting for hardware replacement.
- Cross-organization access: supplier and partner access scoped to named services, with each owner able to withdraw it at their own boundary.
For CTOs and infrastructure leaders, the operational upside is as important as the security one. Service-level policy can stay stable through application moves, cloud migrations and infrastructure refreshes, and Philip proposes measuring the payoff in fewer configuration touchpoints, shorter change lead times and less critical-service exposure.
Four questions to test your architecture
Philip closes with questions any team can ask today:
- Which identity-to-service relationship is actually authorized?
- Can the protected service be reached before authorization, or through a bypass?
- When authority changes, are the affected paths withdrawn within a declared time, without disrupting unrelated access?
- Does observed evidence confirm enforcement, including during failure?
What’s next
The forthcoming CSA paper will propose an IDR Reference Architecture, Core and Enhanced Capability Profiles, and an IDR Try-On Test Pack. It will be presented at the November IDR Zero Trust Summit and opened for peer review, and CSA is inviting practitioners, architects and researchers to challenge the requirements and contribute real-world examples.
At NetFoundry, this is the model we have been building toward with OpenZiti: no open inbound ports, no standing network access, and connectivity that exists only for authorized identities. We’re glad to see it taking shape as an industry framework.
