Ideal: Security systems should protect people without creating unnecessary barriers for legitimate users.

Focus: Authentication usability, accessibility, elderly users, disability access, recovery workflows, and security design that acknowledges real human circumstances.

Central Question: Does a security system protect people while preserving their ability to exercise judgment and control?
Examines the difference between security designed around human realities and security that treats people as obstacles, vulnerabilities, or compliance inputs.

Connects To: Human Agency, Identity, Human Escalation Paths, Invisible Failure.

Human-Centered Security

Research Hub

Security exists to protect people, systems, information, institutions, and the functions on which they depend. Yet security mechanisms can also introduce operational risk when they deny legitimate access, misclassify activity, obscure consequential decisions, or leave affected people without an effective means of investigation or recovery.

Human-centered security examines security architecture and operations from the perspective of the people who depend on them, are subject to their controls, and must respond when those controls fail.

The central concern is not whether a security control exists. It is whether the control achieves its intended protective purpose under real-world operating conditions, how it affects legitimate users, and what happens when it produces an incorrect or harmful outcome.

A security mechanism must be evaluated both by what it prevents and by the failures, dependencies, and consequences it introduces.

Security Is an Operational Relationship

Security is frequently discussed in terms of controls, policies, identities, permissions, detection rules, risk scores, and compliance requirements. These are important components, but they do not independently establish that a system is secure in practice.

A control operates within a larger environment that includes people, workflows, external service providers, automated decisions, escalation processes, evidence repositories, and recovery mechanisms. Its effectiveness depends on those relationships.

A technically valid control can still produce an operationally damaging result. An automated detection mechanism may correctly execute its configured response while acting on an incorrect flag. An access restriction may be applied without an effective process for distinguishing a legitimate user from an actual threat. A recovery procedure may depend on the same identity service, device, or communications channel that has already failed.

These are not necessarily failures of the individual control’s implementation. They may be failures of the assumptions, dependencies, decision processes, or safeguards surrounding it.

Human-centered security examines those conditions rather than treating the control in isolation.

Failure Modes and Areas of Investigation

Automated Decisions and Incorrect Classification

Automated security systems can identify suspicious activity, assign risk classifications, restrict access, and initiate corrective actions. Their outputs can also be incomplete, incorrect, or insufficiently contextualized.

The resulting risk depends on what the system is permitted to do with those outputs.

Research in this area considers how automated flags are created, propagated, changed, and removed; whether consequential actions can be reconstructed; how false positives are handled; and whether affected people have a meaningful path to correction.

The objective is not to assume that automation is inherently unreliable. It is to determine what evidence supports a decision, how uncertainty is handled, and what safeguards exist when the decision is wrong.

Access Restrictions and Loss of Essential Function

Authentication, authorization, account status, device registration, network provisioning, and other dependencies can determine whether a person can use an essential service.

When access disappears, the immediate symptom may not reveal the initiating failure. A restriction may originate in one system and be enforced by another. Different providers may hold different views of the same state. Support personnel may see only part of the transaction history.

Human-centered security asks whether the architecture can distinguish an appropriate security intervention from an erroneous or unexplained loss of legitimate access—and whether the affected person can obtain a timely, evidence-based resolution.

Security Controls That Become Single Points of Failure

A security design may introduce dependencies on a single device, identity provider, authentication factor, recovery channel, administrator, or automated decision service.

Those dependencies can undermine resilience when the primary mechanism fails or becomes inaccessible.

The relevant question is not simply whether an alternative exists in the design documentation. It is whether the alternative remains usable under the failure conditions it is intended to address, without introducing an unacceptable security weakness.

Opaque Enforcement and Limited Recourse

A system may enforce a decision without providing the affected person with enough information to understand or challenge it. Support personnel may lack the authority to reverse the action, while escalation procedures may repeatedly return the person to the same unsuccessful process.

This creates a gap between enforcement capability and remediation capability.

A resilient security architecture should consider both sides: the ability to impose appropriate restrictions and the ability to investigate, correct, and safely reverse restrictions that should not remain in place.

Evidence Integrity and Ability to Investigate

Security investigations depend on records that can support a reliable reconstruction of events.

If relevant logs are missing, altered, incomplete, inconsistent, or inaccessible to investigators, the organization may be unable to establish the sequence of events or determine which component initiated an action.

The absence of sufficient evidence does not, by itself, establish malicious activity. It does establish a limitation on what can responsibly be concluded.

Human-centered security therefore considers evidence preservation, provenance, access to investigative records, independent verification, and the distinction between a confirmed finding and an unresolved attribution question.

Security Must Include the Failure of Security

Security architecture often focuses on preventing unauthorized actions. Operational resilience also requires examining what happens when the security mechanism itself behaves incorrectly, is misconfigured, loses a dependency, or cannot be investigated effectively.

That examination includes questions such as:

What happens when a legitimate user is incorrectly classified as a threat?
Can a security action be traced to its initiating event, decision, and enforcement mechanism?
Are automated decisions subject to appropriate review and correction?
Can a person retain essential functions while a disputed restriction is investigated, where doing so is safe and appropriate?
Can investigators obtain reliable records independently of the component under investigation?
Does recovery restore a trustworthy state, or merely remove the immediate symptom?
Can the organization demonstrate that the corrective action worked?

These questions do not imply that every restriction should be removed on request or that security controls should be weakened to avoid inconvenience. They address the need for proportionality, verifiable decisions, appropriate safeguards, and effective remediation.

A security system that can deny access but cannot reliably explain or correct an erroneous denial has an operational capability gap.

Engineering and Governance Principles

Human-centered security can draw on established security engineering, safety engineering, usability, human-factors research, incident management, and resilience practices. The relevant principles include:

Proportionality. Match the response to the available evidence, the severity of the risk, and the potential consequences of the action.

Transparency appropriate to the threat. Provide meaningful explanations and status information without unnecessarily disclosing sensitive detection logic or information that would enable abuse.

Separation of duties and independent review. Where warranted by the risk, separate the authority to initiate a consequential action from the ability to review its legitimacy and validate its correction.

Auditable decisions. Record relevant decision inputs, state changes, timestamps, responsible systems, and corrective actions with appropriate integrity protections.

Safe recovery. Design recovery processes that do not depend exclusively on the mechanism that failed and that verify restored identity, access, and system integrity.

Effective human escalation. Ensure that escalation routes lead to personnel who possess the necessary information, competence, and authority to resolve the problem.

Testing under failure conditions. Evaluate security controls not only against expected attacks but also against misclassification, dependency failure, contradictory records, unavailable support channels, and unsuccessful recovery.

Accountability across boundaries. Establish responsibilities when a security outcome involves multiple teams, providers, automated systems, or administrative domains.

These principles are not substitutes for a threat model or a formal security assessment. They are dimensions that such assessments should consider when security outcomes affect legitimate users and essential operations.

Research Perspective

This research is grounded in real-world operational problems and the examination of how security mechanisms behave when their assumptions are challenged.

The relevant questions extend beyond whether a policy was followed or a control returned the expected result. They include whether the underlying classification was justified, whether the action was proportionate, whether the available records support the explanation, and whether the affected person or organization could recover.

Observed events must be distinguished from proposed explanations. An unexplained restriction is not, by itself, proof of deliberate targeting. An altered record does not establish who altered it or why without further evidence. Conversely, the inability to establish a cause should not be confused with proof that no failure occurred.

This approach supports rigorous investigation while preserving uncertainty where the evidence does not resolve it.

The purpose is to identify failure mechanisms, assess the adequacy of existing safeguards, and derive practical implications for the design and operation of resilient security systems.

Relationship to Operational Resilience

Human-centered security is closely connected to the other research areas in this hub:

Human Agency examines whether people retain meaningful control and the ability to act when systems affect them.
Human Escalation Paths examines whether the people responsible for resolving security-related failures can actually be reached and can act.
Identity Continuity examines the preservation of legitimate identity and access across disruptions.
Invisible Failure Analysis examines how to investigate failures when their mechanisms or records are not adequately visible.
Recoverability Engineering examines restoration, verification, and the establishment of a trustworthy operating state.
Single-Device Dependency examines the concentration of security and recovery functions in a single device or access path.

Human-centered security contributes the security-specific perspective: how protective controls, automated decisions, enforcement mechanisms, and their dependencies affect people and the resilience of the systems they rely upon.

Research and Publications

This sub-hub is the publication home for research concerning the human consequences and operational behavior of security systems.

Associated papers may address automated classification, access restrictions, security-related state changes, evidence integrity, ineffective remediation, control dependencies, and the gap between stated security objectives and actual outcomes.

Established standards, technical documentation, and authoritative research can provide comparison points where they help evaluate a control, clarify a mechanism, or establish recognized practice. They do not replace the examination of real-world evidence or predetermine its interpretation.

Associated papers and related research artifacts will be listed here and linked to relevant work elsewhere in the Operational Resilience collection.

Governing Question

Does the security architecture protect legitimate users and essential functions even when its own controls, assumptions, dependencies, or decision processes fail—and can those failures be investigated and corrected without sacrificing security or human agency?

Hunter Storm