Hunter Storm

Focus: MFA dependency, SIM-based authentication, device loss, carrier outages, hardware failure, and alternative recovery options.

Central Question: What happens when one device becomes the indispensable gateway to identity, authentication, communications, access, or recovery?
Analyzes the device as a potential concentration point for otherwise separate dependencies. Consider loss, damage, lockout, compromise, battery failure, account recovery, and circular dependencies in which the device needed for recovery is itself inaccessible.

Connects To: Identity, Continuity, Human Agency, Recoverability Engineering.

Single-Device Dependency

 

Overview

Single-device dependency occurs when access to an essential service, account, identity, communication channel, or recovery process depends on one physical device or on capabilities that are available only through that device.

The device may be a phone, computer, hardware security key, or another piece of equipment. The central issue is not the number of devices a person owns. It is whether the loss, failure, compromise, deactivation, or unavailability of one device can prevent the person from accessing essential capabilities or recovering from the disruption.

A device can become a single point of failure even when the surrounding service is distributed, redundant, and designed for high availability. If authentication, account recovery, provider communication, identity verification, and security notifications all depend on the same device, those functions may fail together.

This is a problem of dependency architecture, not merely device management.

 

The Dependency Problem

Modern services frequently use a mobile device for several distinct purposes:

• Authentication through an authenticator application, passkey, or text message.
• Receipt of account alerts, security notifications, and recovery codes.
• Approval of login attempts or changes to account settings.
• Communication with service providers and support personnel.
• Access to email, password managers, identity providers, and other recovery services.
• Verification of identity when another component fails.

Each function may be reasonable in isolation. The risk emerges when multiple functions depend on the same device, account, telephone number, network, or identity provider.

A backup that relies on the same failed dependency is not necessarily an independent backup.

For example, an alternative login method may be ineffective if it requires an approval notification on the unavailable phone. A recovery email may provide little protection if the email account itself requires authentication through that phone. A support process may be inaccessible if the only available contact channel depends on the disrupted service.

The resulting failure can extend beyond the original device or service.

 

Failure Modes

 

1. Loss of the Device

A device may be lost, stolen, damaged, rendered unusable, or otherwise unavailable. The operational impact depends on whether essential functions can be accessed through an independent alternative.

 

2. Loss of Network or Service Access

A functioning device may become unable to connect to a required network or service. Physical possession of the device does not guarantee access to its associated capabilities.

 

3. Loss of the Authentication Path

Authentication may depend on a device, telephone number, application, or security credential that is unavailable or no longer recognized by the relevant service.

If the same authentication path is also required for recovery, the original failure can prevent the user from correcting it.

 

4. Circular Recovery Dependencies

A recovery process may require access to the very account, device, communication channel, or identity service that has failed.

This creates a circular dependency: the user must regain access to recover access.

 

5. Shared Failure Domains

Two apparent alternatives may share a critical dependency. For example, separate applications may both rely on the same mobile operating system, network connection, cloud account, or identity provider.

Redundancy is meaningful only to the extent that the alternatives can survive the relevant failure.

 

6. Loss of Evidence and Notifications

A disrupted device or service may also be the primary means of receiving alerts, preserving records, contacting support, or documenting changes.

The failure can therefore impair both the affected capability and the user’s ability to understand what happened.

 

7. Provider or Account-State Changes

A service provider may change an account’s status, access permissions, authentication requirements, or network availability. The user may have no effective alternative if the affected device or service is also required to contact the provider or verify the account.

The technical cause, authorization, and attribution of such changes must be established through evidence. A loss of access does not, by itself, establish why the change occurred or who caused it.

 

Independence Matters More Than Device Count

Resilience requires examining dependencies, not simply counting devices or backup methods.

A useful assessment asks:

• Does the alternative require the original device?
• Does it depend on the same telephone number, network, account, identity provider, or cloud service?
• Can the alternative be used if the primary authentication method is unavailable?
• Can the person contact the responsible provider without relying on the disrupted service?
• Can account ownership and legitimate access be verified through another reliable process?
• Can essential functions continue while the primary access path is being restored?
• Are there records sufficient to establish what changed and what remains unresolved?

 

An alternative is not independent merely because it has a different name, application, or user interface. Its dependencies must be examined.

 

Engineering and Governance Principles

 

1. Map Critical Dependencies

Document which devices, credentials, accounts, networks, providers, and services support each essential function. Identify dependencies shared by primary and backup paths.

Dependency maps should reflect actual operating conditions, not only the intended architecture.

 

2. Avoid Common Points of Failure

Where practical, design alternative access and recovery methods so that a single device or service failure does not disable every route to essential capabilities.

The appropriate degree of independence depends on the consequence of failure, the threat model, and the cost and feasibility of alternatives.

 

3. Design Recovery That Survives the Original Failure

Recovery should not depend exclusively on the component being recovered. If a phone is unavailable, for example, the process for restoring access should not require approving a request on that same phone.

Recovery methods must also be protected against account takeover, social engineering, and unauthorized changes. Independence does not mean weakening security.

 

4. Preserve Alternative Communication Paths

People need a practical way to contact the responsible organization when its primary service or authentication mechanism is unavailable. The alternative must lead to a process capable of addressing the problem, rather than merely redirecting the person to the failed channel.

 

5. Protect Evidence During Disruption

Where consequential access changes occur, relevant records should be retained and protected against unauthorized modification. Recovery and investigation should not depend solely on records available through the affected device or service.

 

6. Test the Failure, Not Just the Backup

A backup method that has never been tested under realistic failure conditions may not work when needed.

Testing should include scenarios in which the primary device is unavailable, the associated telephone service is disrupted, the primary account cannot be accessed, or the normal recovery channel fails.

Tests should verify the entire process—from initial disruption through authentication, recovery, and confirmation that the restored capability works.

 

7. Define Responsibility Across Providers

Device manufacturers, telecommunications providers, application developers, identity providers, and service operators may control different parts of the dependency chain.

Governance arrangements should establish who can investigate each part, who can authorize corrective action, what evidence is available, and how responsibility is coordinated when a failure crosses organizational boundaries.

 

Human Consequences

A device dependency can affect more than convenience.

If a phone is the sole route to authentication, communications, identity verification, and account recovery, losing access to it may interfere with financial services, work, healthcare communications, personal safety, and the ability to contact the organizations responsible for resolving the problem.

The consequences are particularly serious when a person cannot independently restore access, obtain an explanation, preserve relevant evidence, or reach someone with authority to intervene.

A design that assumes continuous device availability transfers operational risk to the person who depends on the service. That transfer may be invisible until the dependency fails.

Resilience must therefore be evaluated from the user’s actual position during a disruption—not solely from the service provider’s perspective.

 

Evaluation and Assurance

A single-device dependency assessment should consider:

Assessment area	Key question
Critical functions	Which essential capabilities depend on this device?
Dependency concentration	How many functions fail if the device or its associated service becomes unavailable?
Backup independence	Do alternatives share the same critical dependencies?
Recovery	Can access be restored without using the failed component?
Communication	Can the person reach the responsible organization through another channel?
Evidence	Can consequential changes be reconstructed from reliable records?
Human intervention	Is there a practical route to someone who can investigate and act?
Testing	Has the full recovery process been tested under realistic failure conditions?

Useful measures may include the number of critical functions affected by a single failure, the proportion of recovery paths that depend on the primary device, recovery time, the success rate of tested recovery procedures, and the availability of reliable records.

These measures require context. A large number of backup methods does not prove resilience if they share the same failure domain. A short recovery time does not prove that the restored account or system is in a trustworthy state.

 

Research Perspective

This research area examines the gap between nominal redundancy and practical independence.

The work is grounded in real-world technology and operational problems, including situations in which access to a service, the ability to contact its provider, and the ability to establish what happened may depend on overlapping systems.

Analysis distinguishes documented events from technical explanations that remain unconfirmed. It also distinguishes the immediate failure from the architectural conditions that can make the failure more consequential or difficult to recover from.

The objective is to identify dependencies, test recovery assumptions, preserve evidence, and determine which design or governance changes would reduce the likelihood or impact of recurrence.

 

Relationship to the Operational Resilience Research Hub

Single-Device Dependency connects to the other areas of this hub:

• Human Agency: Can a person retain meaningful control when the primary device is unavailable?
• Human-Centered Security: Do security controls preserve legitimate access and provide safe alternatives during failure?
• Human Escalation Paths: Can the person reach someone with the authority and information needed to resolve the problem?
• Identity Continuity: Can legitimate identity and access be established and restored through an independent process?
• Invisible Failure Analysis: Can the failure and consequential changes be reconstructed from reliable evidence?
• Recoverability Engineering: Can the affected capabilities be restored and the result verified?

 

Together, these areas examine how technical dependencies can become human and operational vulnerabilities.

 

Related Research and Publications

This page serves as a publication home for research addressing device dependency, authentication and recovery, shared failure domains, continuity of access, and the operational consequences of concentrated dependencies.

Related papers and supporting evidence will be mapped here as the existing research corpus is inventoried and verified.

 

Governing Question

If one device or its associated service becomes unavailable, can a person retain or recover essential capabilities through an independent, secure, and verifiable process?

The objective is not to eliminate every dependency. It is to identify critical dependencies, prevent avoidable concentration of risk, and ensure that the failure of one component does not automatically eliminate every practical route to access, communication, investigation, and recovery.

 

---

Related Operational Resilience Resources

• Digital Resilience
• Human Agency
• Human-Centered Security
• Human Escalation Paths
• Human-First Systems Design Series
• Identity Continuity
• Invisible Failure Analysis
• Operational Resilience Hub
• Recoverability Engineering
• Single-Device Dependency