Join our Newsletter — 33% off our NHI Course

Single Point of Dependence

A condition where one model, provider, or automated workflow carries an entire category of work. If the model changes behaviour or fails, the organisation has no meaningful alternate path and the same dependency affects multiple downstream decisions.

What a Single Point of Dependence Means

A single point of dependence exists when one model, provider, or automated workflow carries an entire category of work. The problem is not just concentration, but the absence of a meaningful fallback when that dependency changes behaviour or becomes unavailable.

This matters because the dependency is doing more than one task at once: it may shape decisions, execute actions, and influence downstream systems. If one component quietly degrades, the organisation can inherit the same failure across every process that relies on it.

Why It Becomes a Security and Resilience Issue

Single points of dependence create fragility because they collapse diversity in judgment, tooling, or execution into one path. That can turn a quality issue, outage, policy change, or model regression into a broad operational event instead of a contained one.

The security concern is not limited to downtime. If the dependent system is compromised, misconfigured, or manipulated, the failure can propagate through multiple decisions and controls before anyone notices. This is especially important where a shared service is used to classify requests, approve actions, or route sensitive work.

For broader control context, the relationship between trust boundaries, verification, and least-privilege design is well captured in NIST Cybersecurity Framework 2.0 and NIST SP 800-207 Zero Trust Architecture.

Common Forms of Single-Point Dependency

This pattern can appear in AI services, software delivery, identity workflows, policy engines, data enrichment layers, or any automation that becomes the default route for a business function. The technical shape differs, but the risk is the same: one dependency becomes the system of record, the system of decision, and the system of execution.

In practice, the most dangerous versions are the ones that look efficient. Centralisation can reduce duplication and simplify operations, yet it also removes the natural friction that would otherwise reveal failure early. When every path depends on the same provider or model, the organisation may not notice the missing alternatives until it needs them.

Where the dependency is model-driven, governance should also consider how AI control obligations and oversight expectations are framed in NIST AI Risk Management Framework and EU AI Act regulatory framework.

How Organisations Reduce the Blast Radius

The practical goal is not to eliminate every dependency, but to prevent one dependency from becoming irreplaceable. That usually means maintaining an alternate path, preserving manual or independent fallback for critical decisions, and testing whether the business can continue when the primary provider fails or changes behaviour.

Good design also separates roles that are often merged for convenience. A system that evaluates, approves, and executes the same class of work in one place is harder to observe and harder to replace. Independent review, diverse control paths, and explicit recovery expectations make the dependency visible before it becomes a failure mode.

When the dependency is a cloud or external control layer, resilience and supply-chain expectations are reinforced by EU NIS2 Directive and, for software provenance and build integrity, SLSA.

Risk and Threat Considerations

A single point of dependence becomes risky when a shared model, provider, or workflow can affect many decisions at once. The failure may be accidental, but the security impact is similar to a concentrated control failure: one weakness can spread across multiple downstream processes.

Failure mechanism: The dependency is over-relied upon, so any outage, behaviour shift, compromise, or policy change propagates across all consuming workflows and leaves no meaningful alternate path.

Impact: Organisations can lose availability, consistency, decision quality, and response capacity at the same time, with the added risk that a compromised dependency can influence or misdirect multiple systems before detection.

Practitioner Guidance

Why practitioners should care: A single point of dependence is often a design smell before it becomes an incident. If one control, model, or provider is carrying a whole class of work, the question is not whether it is efficient, but whether it can fail safely.

Practitioner note: Treat fallback as a requirement, not a convenience. If you cannot describe what happens when the dependency degrades, changes output, or becomes unavailable, the organisation is already overexposed.