Reduce the deployed system
System hardening removes or restricts functions that the required service does not need. It covers hardware, firmware, operating system, runtime, packages, services, accounts, credentials, network listeners, files, devices, logging, update paths, and recovery.
Hardening is a maintained state, not a one-time checklist. A secure baseline must follow the actual service version, role, environment, and threat model.
Build a role-specific baseline
Start from an inventory and a minimal supported image. Define required ports, processes, packages, files, users, capabilities, syscalls, mounts, devices, network destinations, cryptographic settings, logging, time, update sources, and administrator paths. Remove defaults and samples that add authority or interpreters.
Use configuration as code and immutable artifacts where practical. Verify provenance and signatures. Separate build, deployment, runtime, and emergency credentials. Apply operating-system and runtime protections that are compatible with the service.
Maintain and verify
Continuously compare deployed state with the approved baseline. Detect new listeners, packages, accounts, permissions, kernel modules, scheduled tasks, services, and configuration. Patch through a tested rollout and rollback path. Rebuild from known-good artifacts instead of making undocumented host repairs.
Test the denied behavior. Confirm that the service cannot write protected paths, reach unrelated networks, attach debuggers, load code, use unused devices, or invoke blocked administration APIs.
Failure and residual risk
A generic benchmark can disable a required security function or leave a role-specific risk untouched. Hardened settings can drift during incidents, upgrades, or support work. Removing observability can make attacks harder to detect. An unpatched minimal system can still be vulnerable, and a fully patched system can still have unsafe architecture or credentials.
Hardening does not replace application authorization, network boundary enforcement, or recovery planning. It limits attack surface and consequence within a defined role.
Pomerium boundary
Pomerium publishes supported deployment and upgrade guidance. Operators own the base image, host, container or virtual machine, service identity, network policy, filesystem, administrator access, observability, patch process, and drift detection. A protected administration route does not harden the underlying host.
Evaluation checklist
- Is the baseline specific to this service role, version, environment, and threat model?
- Which listener, package, account, interpreter, mount, device, capability, and outbound route is required?
- Does deployed-state evidence detect drift after upgrade, recovery, and emergency work?
- Can the service operate and be investigated without adding broad administrator access?
- Do negative tests prove that prohibited system and network actions are blocked?
