Protection objective
The system should meet its protection needs through its architecture and lifecycle, without requiring every operator to discover and assemble essential safeguards. A new deployment should begin in the safest practical state for its intended use.
Design and default are different
Secure by design makes protection a system requirement and assigns it to architecture, implementation, verification, operation, and recovery. Secure by default selects safe initial behavior, such as no implicit public access, narrow permissions, strong validation, and disabled unsafe compatibility modes.
Build the lifecycle
Define abuse cases and security requirements with functional requirements. Reduce trusted complexity. Use safe interfaces. Test negative behavior. Provide secure update, observability, vulnerability response, and recovery. Make dangerous changes deliberate and visible.
Failure and limits
A secure default can be changed. A strong architecture can be deployed with an exposed alternate path. Defaults can also harm availability or usability and cause operators to bypass them. Measure how the product is deployed, not only what the template contains.
Pomerium boundary
Pomerium is designed to put policy enforcement before protected routes, but deployment choices determine whether the upstream remains reachable around it and whether policy is narrow. Applications need their own secure defaults for object permissions, sessions, data, and administration.
Evaluation checklist
- Are protection needs present in system requirements and architecture?
- Does a new resource begin inaccessible until an explicit grant exists?
- Are dangerous changes deliberate, attributable, and testable?
- Can operators recover without creating an undocumented bypass?
- Does deployment evidence show that the intended secure state exists?
