Platform and application owners share accountability. Platform teams should define the migration path, communicate deprecation timing, and provide replacement patterns. Application teams must remediate the objects they own and validate traffic behaviour after cutover. Governance should track exposure, because deprecation warnings are a control signal that the migration has not been completed.
Why Accountability For Deprecated Ingress Does Not Sit In One Team
When deprecated Kubernetes ingress resources remain in production after a platform migration window, accountability is shared because the failure spans platform governance and application ownership. Platform teams define the migration standard, publish the replacement path, and set the cutover date. Application teams control the workload-specific objects and must remove or replace the legacy ingress before the window closes. This is not just housekeeping: lingering ingress can preserve an outdated exposure path, confuse traffic routing, and undermine the migration itself. For control context, NIST SP 800-53 Rev 5 Security and Privacy Controls treats configuration governance and change control as continuing obligations, not one-time events. In practice, many teams discover the ownership gap only after the deprecated path is still serving traffic and the migration window has already closed.
How Migration Windows Turn Into Operational and Security Debt
A migration window is meant to be a bounded period in which legacy ingress is still tolerated while teams update manifests, routing, certificates, and any attached policy or observability rules. The accountability question matters because the platform layer and the workload layer fail in different ways. Platform owners usually own the standard: which ingress class is approved, what the supported replacement looks like, how long the old pattern stays accepted, and what telemetry should prove completion. Application owners own the resource itself and the traffic behavior it controls. If they leave deprecated ingress in place, they are usually preserving an object that no longer matches the intended platform state.
Operationally, this creates three common failure conditions. First, the old ingress keeps routing even after teams believe cutover is complete. Second, multiple ingress patterns coexist, which makes troubleshooting harder and increases the chance of policy drift. Third, deprecation warnings become background noise instead of an actionable signal. That is why migration tracking should not be treated as a generic project task; it is a control verification problem. If deprecated ingress is still present, someone has not completed the change, even if adjacent platform work is finished.
- Platform teams define the supported target state and the deprecation deadline.
- Application teams remove the resource, validate routing, and confirm no unexpected fallback remains.
- Governance teams confirm that warning signals are tied to owners and not left as passive alerts.
This guidance breaks down when ownership of the workload itself is unclear, because then even a well-documented migration path cannot be enforced reliably.
Where Responsibility Gets Blurry In Shared Kubernetes Operations
Tighter platform standardisation often reduces drift, but it also increases coordination overhead, so organisations have to balance faster migration against the cost of retraining teams and reworking manifests. The clearest ambiguity appears when ingress is generated by shared templates, GitOps pipelines, or a platform service team that deploys on behalf of applications. In those cases, the accountable party is not always the same as the party that applies the change.
Guidance versus consensus: there is broad agreement that the platform team owns the deprecation policy and the application team owns the workload object, but organisations vary on whether central platform engineering may directly remove deprecated resources after the deadline. That decision depends on change authority, blast radius, and whether traffic interruption risk is acceptable. A sensible rule is to treat unresolved deprecated ingress as an exception that must be explicitly accepted, not as a silent extension of the migration window.
Another edge case appears when deprecated ingress is still present but not actively receiving traffic. Even then, it can remain a security and governance issue because dormant objects often outlive the assumptions that justified them. They may still expose old hostnames, outdated TLS settings, or undocumented routing behavior. The practical standard is simple: if the object is still deployable, observable, and linked to production, it is still in scope for accountability.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-01 — Organisational Context | Defines ownership and governance for migration accountability. |
| GV.SC-05 — Policies, Processes and Procedures | Applies to deprecation timing, replacement standards, and cutover rules. | |
| ID.IM-01 — Improvements | Deprecated ingress indicates a control gap that should be tracked to closure. | |
| Recommendation — Assign clear owners for deprecated ingress and document the migration decision path. Set and enforce deprecation procedures with a fixed cutoff and approved replacement pattern. Track deprecated ingress as an improvement item until the legacy object is removed. | ||
| CIS Controls v8 | 4.1 — Establish and Maintain an Inventory of Assets | Production ingress resources must be inventoried to know what still exists. |
| 4.2 — Address Unauthorized Assets | Deprecated resources left behind become unmanaged production exposure. | |
| 4.4 — Use of Supported and Approved Services | A migration window should end with supported ingress patterns only. | |
| Recommendation — Maintain an accurate inventory of production ingress objects and retire stale entries promptly. Remove or formally accept deprecated ingress that remains active beyond the migration window. Migrate workloads to approved ingress patterns and stop using deprecated implementations. | ||
Practitioner Guidance
What to prioritise: Assign one named owner for the deprecated object and one named owner for the migration program. Shared accountability works only when each side has a different decision to make: platform owners set the boundary, and application owners remove the resource and prove the cutover worked.
What to verify: Confirm that deprecation notices are tied to a live inventory of production ingress, not just a change announcement. The useful proof is evidence of removal, replacement, and post-cutover traffic validation, because warning visibility alone does not mean the migration has completed.
Escalation / exception: If a deprecated ingress remains after the deadline, treat it as an exception requiring explicit risk acceptance or enforced remediation. Do not leave it in a “pending” state, because that is how migration windows turn into indefinite legacy support.
Practitioner takeaway: The key judgement is that platform teams own the standard and timeline, but application teams own the actual cleanup and validation, so unresolved deprecated ingress should always be treated as an accountable miss rather than an unavoidable leftover.
Related resources from NHI Mgmt Group
- How should teams handle Kubernetes Ingress Controller migration when deprecated ingress types are still in use?
- What do platform teams get wrong about ingress migration?
- Who should be accountable for retiring legacy ingress in Kubernetes?
- How should platform teams govern Kubernetes-native API gateway resources?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
