Keeping service reachability aligned with authorisation · where does…

I’m developing a CSA paper on Identity-Defined Reachability (IDR) and would welcome criticism of the model, particularly from people implementing this across mixed environments.

The problem is familiar: identity policy, network reachability and application permissions have different scopes and lifecycles. An approved application-to-database relationship can require changes across several systems and teams. Removing that authority doesn’t necessarily remove the usable path or terminate existing connections.

AI adds pressure in both directions: faster attacks against reachable services, and more frequent changes to legitimate communication. But the underlying problem applies equally to enterprise applications, industrial equipment and supplier access.

The IDR proposal is that a usable path to a named protected service is absent by default and exists only while the relationship is authorised. A valid identity alone isn’t enough; service binding, policy and current context matter too.

Those relationships form a permitted and governed communication graph, with each identity-to-named-service relationship serving as a common and consistent unit of authority, reachability, enforcement and observation.

For example, a change in workload posture should be traceable through the authorisation decision to the affected connections being withdrawn. We should be able to verify that withdrawal, prevent unauthorised reconnection and show that unrelated authorised communication continued.

This builds on SDP and resource-centric Zero Trust. Application and transaction controls still govern what happens within an authorised connection, and public admission interfaces still need protection.

The difficult cases interest me most. If multiple users share an application’s database connection, withdrawing one user’s authority cannot simply mean closing that connection for everyone. The enforcement scope has to match the authority being withdrawn, with application enforcement handling distinctions the connectivity layer cannot make.

Where have you managed to keep these states aligned, and where do shared infrastructure, legacy systems or availability requirements get in the way?

The blog introduces the model and the assessment work planned for the paper. The main argument is above; no need to leave Reddit to discuss it (though it has 2 pictures/figures, which I think are nice and which show both the difference in relationships and each identity-to-named-service relationship becomes a common and consistent unit of authority, reachability, enforcement and observation).

Disclosure: I wrote the blog, work at NetFoundry and co-lead CSA’s Zero Trust networking workstream. The paper is intended as vendor-neutral guidance.

Impact

The impact of adopting IDR is primarily a reduction in unnecessary network exposure and improved alignment of reachability with authorisation, which can reduce the attack surface and limit the window of opportunity for attackers. It addresses risks where services remain reachable after authority is revoked, potentially allowing unauthorized access or exploitation. The model supports faster and more precise revocation of access in dynamic environments, which is increasingly important given the speed of AI-driven attacks and frequent changes in legitimate communication. However, the content does not describe a specific vulnerability or exploit but rather a conceptual framework to improve security posture.

Defensive guidance

This content does not describe a vulnerability with a patch or direct remediation steps. Instead, it proposes a security model (IDR) that organisations can consider adopting to better align service reachability with authorisation. Implementers should evaluate their environments for misalignments between identity, network, and application controls and consider strategies to enforce reachability only while authorisation is valid. The model builds on Zero Trust principles and may require coordination across teams and systems. No immediate patch or fix is applicable.

Summary

The blog and discussion introduce Identity-Defined Reachability (IDR) as a model to ensure that network reachability to services is tightly coupled with authorisation decisions. Traditional environments often have misaligned states across identity, network, and application layers, leading to unnecessary exposure. IDR enforces that a usable communication path exists only while the identity-to-service relationship is authorised, verified cryptographically, and contextually valid. This approach forms a permitted communication graph where each identity-to-named-service relationship is a unit of authority and enforcement. The model builds on existing Zero Trust frameworks and addresses challenges such as shared infrastructure and legacy systems. It aims to reduce the attack surface by removing standing reachability outside authorised relationships and to improve governance and observation of connectivity changes. The content is a strategic proposal and request for community feedback rather than a report of a specific exploit or vulnerability.

Keeping service reachability aligned with authorisation · where does this break down in practice?

Discussion

Impact

Defensive guidance

Summary

References

Community reviews

Discussion

AI analysisMachine-generated, updated 2 Nov 2026, 16:58 UTC

Technical details

References

Community reviews