Learning outcomes
- Separate secret key material from security design that can be reviewed openly.
- Find incentives and friction that drive bypass, sharing, and unsafe recovery.
- Make the secure action clear, available, and easier than a hidden workaround.
- Test normal, error, emergency, and recovery flows with real operators.
Protection need
A control fails when users and operators cannot complete legitimate work, understand the result, recover safely, or distinguish a real request from a deceptive one. Security must remain valid when design details are public. Only keys, credentials, and explicitly secret data should carry secrecy.
Security objectives and requirements
- Show the resource, action, identity, reason, duration, and consequence at the point of decision.
- Make the least-privilege path easier than credential sharing or broad standing access.
- Give denial and failure messages enough information for safe correction without exposing sensitive policy.
- Provide accessible enrollment, approval, revocation, emergency, and recovery flows.
- Keep emergency authority narrow, expiring, and visible.
- Make system state and policy changes observable to the people who must act.
Security invariants and evidence
The normal approved task can finish without a hidden bypass. A denial does not train users to approve blindly. Recovery cannot silently defeat stronger authentication. An operator can tell which policy and version applies. Emergency access expires and leaves evidence.
Test with representative users and operators. Measure completion, errors, retries, abandonment, support work, bypass use, time to revoke, and recovery outcomes. Review incentives: a control that transfers all cost to the user invites avoidance.
Failure cases
- Users share a service account because individual enrollment is slow.
- Approval dialogs omit the target action and become habitual clicks.
- A secure route fails often, so teams keep a direct origin.
- Recovery support can reset stronger authentication without equivalent assurance.
- Operators cannot explain a denial and grant broad temporary access.
- Secret design details are treated as the primary defense.
Design tradeoffs and residual risk
More context helps decisions and can overload users. Strong friction protects high-impact actions and can push work to unmanaged paths. Self-service reduces support delay and increases the importance of identity proofing and audit. Automation improves consistency and can magnify one bad default.
Residual risk includes deliberate insider abuse, deceptive but valid requests, inaccessible recovery, and incentives outside the system boundary.
Pomerium boundary
Pomerium can provide a consistent identity-aware route and policy experience. Operators own enrollment, identity-provider prompts, application permissions, support, recovery, emergency access, and the availability of the protected service. A usable gateway cannot repair a confusing or unsafe application action.
Exercise
Observe five representative people complete enrollment, normal access, one denial, approval of a high-impact action, revocation, and recovery in staging. Do not coach them. Record errors, abandoned work, copied credentials, direct-route attempts, and support needs.
Redesign the highest-risk friction point. Repeat the task and prove that the safe path is clearer without broadening authority or weakening recovery.
Evaluation checklist
- Can a person identify the resource, action, authority, and consequence before approval?
- Is the secure path available and easier than a bypass?
- Do denials and failures support safe correction?
- Does recovery preserve the required assurance and revoke old authority?
- Do tests include normal users, administrators, emergencies, and accessibility needs?
Next learning unit
Secure by Design and by Default
Build security into system requirements and architecture, then ship the safest practical configuration as the default.
