Security people can operate
Usable security applies human-centered design to security goals. A control must let the intended person complete the real task accurately, efficiently, accessibly, and with enough understanding to avoid unsafe workarounds. Security is not usable when success depends on exceptional vigilance or undocumented expert knowledge.
Task and context
Study the complete job, not one prompt. Include enrollment, normal use, denial, interruption, device change, travel, accessibility, support, emergency, revocation, and recovery. Identify time pressure, frequency, competing goals, available devices, collaboration, and consequence of delay.
Show the person the resource, action, identity, destination, reason, duration, and consequence that matter. Hide implementation detail that does not help the decision. Make safe defaults and common safe actions easy.
Errors and workarounds
Treat error as system evidence. Repeated credential sharing, direct origins, broad temporary roles, ignored warnings, and support exceptions show that the designed path does not fit the work. Find the cost, delay, missing information, or unavailable recovery that caused the workaround.
Use representative users in realistic conditions. Measure completion, wrong actions, retries, abandonment, support calls, time, accessibility, recovery, and later revocation. Do not score only whether a person clicked a simulated phish.
Failure and residual risk
More context can overload a decision. More prompts create habituation. Self-service recovery reduces delay and can increase takeover risk. A clear interface cannot make an unsafe protocol or broad authority safe. Deliberate abuse and compromised endpoints remain possible.
Usability can conflict across roles. A control easy for an administrator can impose hidden work on every user. State whose task and cost the design optimizes.
Pomerium boundary
Pomerium can provide a consistent access entry and policy result for covered routes. Operators own identity-provider prompts, route naming, application permissions, approval context, support, emergency, and recovery. A clear gateway page cannot repair an unsafe application action or a weak provider recovery process.
Evaluation checklist
- Can representative people complete enrollment, normal work, denial correction, revocation, and recovery without a hidden bypass?
- Does each decision show the real resource, action, identity, destination, duration, and consequence?
- Which delay, workload, accessibility, or incentive produces sharing, blanket approval, or direct access?
- Are errors and workarounds measured as design evidence instead of blamed on users?
- Does the safe path remain safe under support, emergency, device loss, and time pressure?
