Tangle

A cyclic dependency between code components, where each side depends on the other. Tangles make testing, refactoring, and module extraction harder because the components can no longer be changed independently without affecting each other.

Expanded Definition

A tangle is a structural coupling problem in software design, not a security control by itself. It occurs when two or more modules, classes, or services depend on each other in a way that creates a cycle, so a change in one component forces change in the other. In practice, this makes code harder to reason about, harder to test in isolation, and harder to extract into cleaner boundaries.

Unlike a simple dependency, a tangle removes the directionality that healthy architectures rely on. The issue is especially visible in systems that grew quickly, where convenience integrations, shared utilities, or ad hoc exceptions slowly replaced explicit interfaces. In cybersecurity and identity engineering, tangles often appear in authentication, authorisation, logging, and policy layers when teams add shortcuts rather than preserve separation of concerns.

Definitions vary across vendors and engineering communities on whether a tangle is a design smell, an architectural anti-pattern, or a code quality defect, but the underlying signal is consistent: independent evolution has been lost. For broader governance context, NIST Cybersecurity Framework 2.0 emphasises maintainable, manageable security capabilities that are easier to control when system boundaries are clear. The most common misapplication is calling any dependency a tangle, which occurs when teams confuse normal one-way coupling with a true circular dependency.

Examples and Use Cases

Implementing modular boundaries rigorously often introduces short-term refactoring cost, requiring organisations to weigh delivery speed against long-term maintainability.

• A user service calls a policy service, while the policy service also calls back into the user service to fetch attributes, creating a cycle that blocks isolated testing.
• An identity platform shares the same utility library for token validation and audit logging, then those utilities begin importing business logic from the platform itself, making extraction difficult.
• A permissions engine depends on application state to compute access, while the application depends on the engine for every page load, so neither component can be deployed independently.
• A security alert pipeline reads configuration from a module that also consumes pipeline output, causing change requests in one layer to break the other.
• A refactor is attempted to split a monolith into services, but the old code base still contains hidden circular imports that must be removed before any clean boundary exists.

Practitioners often use static analysis, dependency graphs, and architecture reviews to expose these cycles early. When the issue is tied to identity workflows, separation between authentication, session handling, and authorisation should be explicit so that policy decisions do not depend on the components they are meant to govern. That discipline is consistent with the maintainability goals reflected in NIST Cybersecurity Framework 2.0.

Why It Matters for Security Teams

Tangles matter because they reduce the reliability of systems that security teams depend on for control enforcement, evidence collection, and safe change management. When security logic becomes circular, teams may hesitate to patch, tune, or isolate one part of the system because every change risks breaking another. That creates a maintenance penalty that is not just technical but operational, especially in environments where audit trails, approval paths, and policy checks must remain trustworthy.

In identity-heavy environments, tangles can blur accountability between the system that authenticates a subject and the system that decides what the subject may do. That overlap makes it harder to prove which layer owns trust decisions, and it can also obscure defects that affect privileged access, session validation, or logging integrity. From a governance perspective, clear module boundaries support clearer control ownership and easier assurance.

Security teams usually encounter the real cost of a tangle only after a failed refactor, an emergency patch, or a production incident reveals that no component can be safely changed on its own, at which point the tangle becomes operationally unavoidable to address.