Identity-Defined Reachability: Reducing Exposure and Connectivity Friction in an Age of Machine-Speed Attack

AI is changing both the speed of attack and the speed at which organisations need to create, change and retire trusted communications. A supplier’s engineer needs a diagnostic service. An application needs a database. An AI agent needs an approved tool. Each requirement concerns a specific identity-to-service relationship.

Today, that relationship is usually represented across separate control systems: identity and access policy governs authority, network controls create reachability, and application controls govern permitted operations. Those states are not necessarily the same or synchronised. A service may be reachable before the specific relationship is authorised, or remain reachable after authority changes.

CSA’s AI Vulnerability Storm research describes accelerating vulnerability discovery and exploitation. Verizon’s 2026 DBIR identifies exploitation as the leading initial-access vector (31% of breaches), with median full remediation of critical known-exploited vulnerabilities taking 43 days—even as exploitation can begin within hours of disclosure. Meanwhile, distributed applications and agentic systems demand faster changes to permitted communication, making unnecessary reachability more dangerous and topology-dependent connectivity harder to govern.

That is the gap Identity-Defined Reachability (IDR) addresses. In connect-first environments, authority is translated into addresses, routes, firewall rules and exceptions that must stay aligned as identities, permissions and infrastructure change. Repeating this work across systems and teams creates a connectivity tax and slows modernisation. Even a rejected request can expose a reachable component’s listener or parser to attacker-controlled traffic.

IDR reverses that dependency: protected-service reachability becomes a current authorisation outcome. A usable path is absent by default and exists only while cryptographically verified caller identity, verified endpoint authority to represent the named service, applicable policy and context support the relationship. A valid identity alone is insufficient: authority may be scoped to a task or session and end while the identity remains valid.

The set of currently authorised relationships forms a permitted and governed communication graph. Each identity-to-named-service relationship becomes a common and consistent unit of authority, reachability, enforcement and observation. When authority ends, the affected path is withdrawn: no standing reachability outside currently authorised relationships.

Figure 1. Underlay transport and containment remain; policy determines which protected-service relationships become usable.

This model builds on established Zero Trust foundations. CSA’s SDP Architecture Guide v3 develops authorisation before protected connectivity, service-specific access and dynamic enforcement. The ZT Microsegmentation Guidance distinguishes topology-defined containment from connection-defined admission. NIST SP 800-207 and SP 800-207A centre protection on resources and identity-based service access. IDR brings these ideas together around the authorised identity-to-named-service relationship as the common object of policy and enforcement.

Figure 2 zooms into one relationship within that permitted communication graph. Caller-side and resource-side authority, identity, device or workload posture, network context, application and data conditions, and runtime evidence can all inform whether the relationship remains permitted. IDR enforcement keeps usable reachability aligned with that decision, while observed communication and runtime evidence support verification and reassessment.

Figure 2. One relationship within the permitted communication graph: authority and evidence determine whether the reachability edge remains usable; enforcement and observation close the loop.

Either side of the relationship may impose conditions or withdraw its authority. Continuous identities ongoing evaluation of identity and context can inform reassessment of affected relationships. IDR gives that reassessment a concrete reachability consequence: where authority no longer holds, withdraw affected established paths within a declared bound and prevent unauthorised reconnection.

Existing systems can participate through defined interfaces. SPIFFE provides verifiable workload identity, AuthZEN conveys authorisation requests and decisions, while Shared Signals/CAEP - including emerging workload security events through WISE - supplies signals that trigger reassessment of affected service relationships.

Developers and service owners can define identity-to-service relationships as part of application delivery, reducing separate network provisioning. Shared identity, policy and security capabilities govern those relationships throughout their lifecycle, while the fabric enforces service reachability over available transport.

This gives decisions across Zero Trust pillars and cross-cutting capabilities a concrete enforcement consequence:

• Identity and devices: Identity, entitlement, and required posture determine whether affected service relationships remain permitted.
• Applications and data: Task state, data sensitivity, and findings from app controls, runtime monitoring or selective inspection can trigger reassessment of affected service relationships. Application and data controls continue governing operations and information.
• Visibility and analytics: Correlate identity, policy, and observed communication to identify changes and gaps between intended and actual reachability.
• Automation and orchestration: Turn accepted signals into reassessment and selective withdrawal, including established communication, then verify the result.

These behaviours support CISA ZTMM v2 characteristics including dynamic least privilege, coordinated controls, integrated visibility and automated response, while organisation-wide maturity still requires broader assessment.

The same foundation supports several use cases:

• For agentic AI, identity, mission, task state and explicit dependency policies govern which tools and services are reachable as workflows change. A PR-review agent, for example, could reach an internal CI service only during an assigned review, while application controls govern permitted operations and data.
• For enterprise microsegmentation, the same identity-to-service model can constrain reachability across traditional applications, workloads, and non-agentic AI infrastructure as they move or scale. Policy remains tied to the relationship rather than addresses, reducing repeated network reconfiguration and containing compromise without disrupting unrelated authorised communication.
• In Operational Technology (and critical infrastructure), enforcement around legacy equipment can improve security and connectivity without waiting for asset replacement, decoupling the pace of those improvements from industrial replacement cycles.
• Across organisations, supplier and partner access can be scoped to named services, with each participating owner able to deny or withdraw the relationship at its boundary.

The paper makes this accessible through four questions:

• Which identity-to-service relationship is authorised?
• Can the protected service be reached before authorisation or through a bypass?
• Does changed authority withdraw the affected established paths within declared bounds, prevent unauthorised reconnection, and preserve unrelated authorised communication?
• Does observed evidence confirm enforcement, including during failure?

Service-level policy can remain stable through application moves and infrastructure refreshes, provided service bindings and required conditions remain valid. Migration can then proceed through bounded, testable service relationships. For PQC, cryptographic endpoints still require change, but tested integration, policy and validation patterns can be reused.

Measure the resulting benefit through fewer configuration touchpoints, shorter change lead times, lower recurring effort, reduced critical-service exposure, and maintained continuity during migration and containment.

Reachability is not the whole authorisation problem. IDR governs whether the conversation may exist; application and transaction controls govern what may occur within it. Deliberately public admission interfaces require separate protection.

The forthcoming paper develops a proposed CSA IDR Reference Architecture, Core and Enhanced Capability Profiles, and an IDR Try-On Test Pack.

The November IDR Zero Trust Summit presentation will introduce the work and open the paper for peer review. Practitioners, architects, and researchers are invited to challenge the requirements and tests, and contribute operational examples and limitations. The aim is practical guidance that organisations can implement and verify.