Threat-Model a Human Security Workflow

Assets and security objectives

Choose a real task such as account recovery, privileged approval, vendor onboarding, payment change, production access, secret rotation, or incident containment. Protect the account, resource, data, authority, evidence, and person's ability to finish legitimate work.

State both security and task objectives. Example: an on-call engineer can receive time-bounded production access within ten minutes during an outage, but no caller, single support operator, or compromised mailbox can grant that access to another person.

Actors and components

Include requester, approver, support, administrator, manager, vendor, attacker, insider, identity provider, device, authenticator, browser, messaging, ticket, directory, policy service, application, audit system, and recovery owner. Record each actor's goal, workload, knowledge, incentives, authority, and consequence.

Include accessibility needs, language, device loss, poor connectivity, time pressure, sleep disruption, and organizational hierarchy. These conditions are part of the deployed system.

Trust boundaries

Mark transitions between person and interface, message and known channel, identity proof and account, account and authenticator, approval and action, gateway and application, support and identity administration, and evidence and investigation.

Identify which facts come from the requester, a trusted system, public information, prior tickets, or operator judgment. An internal-looking message and accurate personal facts are not independent proof.

Normal request path

Trace discovery, sign-in, request, context display, approval, action, notification, evidence, expiry, and review. Record exact resource, action, identity, destination, scope, duration, reason, and consequence at each step.

Observe representative people performing the task without coaching. Measure time, confusion, retries, unsafe copying, alternate channels, support need, denial recovery, and revocation. Ask them to explain what they believed would happen.

Failure path: deceptive urgent request

An attacker impersonates an executive or colleague, uses accurate internal facts, and creates urgency. The target sees a generic approval or support ticket without trustworthy resource and action context.

Use independent known-channel verification, action-bound approval, named destination, high-impact delay or dual control, phishing-resistant authentication, notification, and fast reporting. The interface must show trusted normalized facts rather than the requester's description alone.

Failure path: unavailable secure path

The approved route is slow or inaccessible during an incident. Staff keep a shared account, direct origin, broad emergency role, or undocumented support exception so work can continue.

Provide tested accessible recovery and emergency paths with narrow authority, expiry, independent evidence, and cleanup. Measure availability and time. Remove the persistent bypass after proving the safe path meets the task need.

Failure path: routine prompt habituation

The person receives many similar MFA, consent, approval, or alert prompts. Normal work requires approval, so an attacker-generated request looks routine.

Remove unnecessary prompts, rate-limit requester-generated prompts, bind the remaining decision to resource and action, provide safe denial, and detect repeated or anomalous requests. Test under realistic prompt volume.

Control redesign and evidence

For each failure, prefer controls that change the system: origin-bound authentication, safe default, narrow permission, independent channel, technical transaction binding, separation of duty, automatic expiry, and simple reporting. Use learning to explain the safe path, not to compensate for a missing control.

Collect task success, error, bypass, report, response, revocation, accessibility, and recovery evidence. Repeat testing after deployment because workload and incentives change.

Design tradeoffs and residual risk

More verification adds time and can block urgent legitimate work. More context can overload people. Dual control reduces one-person abuse and can create collusion or availability risk. Automated risk scoring can hide bias and error.

Residual risk includes deliberate insiders, compromised endpoints, coercion, convincing but valid requests, and organizational incentives outside the interface. Assign an owner and response for each.

Pomerium boundary

Pomerium can protect the routes used by requesters, approvers, and support and can provide route-level identity evidence. Identity-provider recovery, application actions, support authority, approval display, emergency state, and lifecycle remain owned by those systems. Model direct routes and action-level permissions outside Pomerium.

Exercise

Select one high-impact workflow. Observe three representative people complete normal, denied, urgent, and recovery cases. Create a task and authority map, then run the three failure paths above.

Replace at least one vigilance-dependent step with technical binding and remove one persistent bypass. Repeat the test. Show improved task success without broader authority, weaker recovery, or hidden operator work.

Evaluation checklist

• Are the person's real task, environment, authority, incentives, accessibility, and consequences present?
• Does trusted system data show the exact identity, resource, action, destination, scope, duration, and effect?
• Can deception, unavailable normal service, or repeated prompts trigger an unsafe exception or habitual approval?
• Did the design remove vigilance dependence before assigning more training?
• Do tests cover representative people, pressure, denial, emergency, recovery, revocation, and direct paths?