Security teams should migrate policy enforcement to validating admission controls backed by OPA and Pod Security Standards. That preserves workload checks while expanding coverage beyond the original PSP limits. A practical migration path is to validate manifests early, enforce baseline controls first, and then tighten to restricted policies where applications can support them without breaking legitimate workloads.
Why Pod Security Policy was always the wrong long-term control
Pod Security Policy was powerful, but it mixed admission control, workload hardening, and policy design into one Kubernetes feature with a large operational footprint. That made it difficult to standardise across clusters and brittle to maintain. The practical replacement is to separate concern, use admission controls for enforcement, and express workload policy in a way that can evolve without tying security to a deprecated API.
That shift matters because the control problem did not disappear when PSP was removed. Teams still need to decide which pods may run, which privileges are acceptable, and how to keep those decisions consistent across namespaces, clusters, and deployment pipelines.
What should replace PSP in day-to-day enforcement
For most teams, the replacement is a combination of validating admission controls and Pod Security Standards. Admission controls let you block or mutate manifests before they reach the cluster, while Pod Security Standards give you a simpler baseline for common pod hardening expectations. Together, they preserve policy enforcement without forcing every rule into a single deprecated mechanism.
This works best when you treat the admission layer as the enforcement point and the standards as the policy floor. The admission policy can catch cluster-specific exceptions, while the pod security profile handles the baseline workload posture. That separation is cleaner than depending on legacy PSP behaviour and easier to extend when teams need context-aware rules.
OPA is often used here because it can express richer conditions than the built-in pod security model, especially when you need namespace-specific exceptions, image controls, or deployment-time checks. For teams that are already standardising Kubernetes governance, NIST SP 800-190 Container Security is a useful reference point for thinking about image, registry, orchestrator, and runtime risk together. It helps frame admission control as one part of a larger container security posture, not a standalone fix.
How to migrate without breaking legitimate workloads
The safest migration path is incremental. Start by validating manifests in a non-blocking mode, identify the workloads that rely on unsafe defaults, and then move toward enforcement namespace by namespace. Many breakages come from implicit privilege assumptions, so the first pass should focus on discovery rather than hard denial. That lets security teams learn where workloads depend on host namespaces, privilege escalation, or unrestricted volume mounts before they flip the control to mandatory.
Baseline-first migration is usually the best compromise. Enforce the common controls that are rarely justified, then tighten only where the application owner can show that the stricter policy will not disrupt legitimate runtime behaviour. This avoids turning the replacement control into a sudden availability problem and gives platform teams a repeatable way to separate technical necessity from habit.
At the same time, policy authors should think beyond the old PSP shape. One of the reasons PSP was hard to sustain is that it often became a narrow checklist instead of a broader workload governance model. If your cluster policy never looks at manifest provenance, image hygiene, or namespace ownership, you will replace one deprecated control with another incomplete one.
Where teams usually underestimate the migration
The biggest gap is not usually the admission engine itself, but the surrounding operating model. Policy drift, exception handling, and namespace ownership all become more visible once PSP is removed. If teams cannot tell who owns each exception, or if admission rules are copied cluster to cluster without review, the new control will become inconsistent very quickly.
Another common mistake is treating Pod Security Standards as if they were a full replacement for workload policy. They are a strong baseline, but they are intentionally narrower than many PSP deployments were. If you used PSP to enforce image allowlists, hostPath restrictions, or environment-specific exceptions, you still need a separate policy layer to preserve that coverage.
Risk and Threat Considerations
Replacing PSP poorly can leave a gap between the old enforcement model and the new one, especially if clusters are running with inconsistent admission settings or permissive namespace defaults. The main exposure is not just misconfiguration, it is the possibility that privileged or over-permissive pods continue to run because no equivalent policy gate was put in place.
Failure mechanism: Legacy PSP rules are removed before validating admission policies and pod security baselines are fully enforced, allowing workloads to launch with excessive privilege, unsafe mounts, or unsafe namespace access.
Impact: Attackers or misconfigured deployments can gain a larger blast radius inside the cluster, making lateral movement, container escape conditions, and uncontrolled workload behaviour more likely.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Pod admission policy should enforce least privilege for workloads and containers. |
| CM-7 — Least Functionality | Replacing PSP requires removing unsafe pod capabilities and runtime features by default. | |
| Recommendation — Enforce least privilege by denying pods that request unnecessary capabilities or elevated access. Deny unnecessary pod features and allow only approved runtime capabilities. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Kubernetes admission policy is a secure-configuration control for cluster workloads. |
| CIS-5 — Account Management | Pod policies often depend on namespace and service ownership, making control ownership material. | |
| Recommendation — Standardise Kubernetes workload settings and block insecure defaults through policy enforcement. Tie policy exceptions and approvals to named owners and review them regularly. | ||
| OWASP ASVS | V13 — Configuration | Admission controls and pod security profiles are configuration controls that shape deployment security. |
| Recommendation — Validate deployment configuration before release and reject insecure runtime settings. | ||
Practitioner Guidance
What to prioritise: Build the replacement around the highest-risk workload privileges first, not around a one-for-one feature swap. Focus on admission points where a denied manifest is cheaper than a runtime exception.
What to verify: Before enforcing, confirm that every namespace has an owner, every exception is time-bound, and every policy rule is tested against real deployment manifests rather than only synthetic examples.
Practitioner takeaway: The goal is not to recreate PSP exactly, but to replace it with a clearer control model that is easier to operate, easier to audit, and harder to bypass.
Related resources from NHI Mgmt Group
- How should security teams decide whether JIT access is safe for non-human identities?
- How should security teams implement policy as code across Kubernetes and Terraform?
- How should security teams govern authorization when policy runs in Kubernetes and at the edge?
- How should security teams govern Kubernetes pod logs in production environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
