Who is accountable when legacy RSA and ECC certificates remain in use past migration deadlines?

Why This Matters for Security Teams

When RSA and ECC certificates stay in production past migration deadlines, the problem is rarely the crypto itself. The real failure is accountability: no one is clearly responsible for inventory, owner mapping, exception review, and enforcement. That gap turns migration into an unowned backlog item, even as certificate expiry continues to drive outages and risk. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls makes assignment and monitoring a control issue, not an administrative preference.

NHIMG research shows how often this becomes a visibility problem in practice: the Critical Gaps in Machine Identity Management report found that 59% of companies face greater difficulties auditing machine identities because of unclear ownership and limited visibility. That pattern is directly relevant to certificate migration, where legacy RSA and ECC assets often survive long after policy deadlines have passed. In practice, many security teams encounter expired migration exceptions only after a production certificate fails or an audit requests evidence that no one can produce.

How It Works in Practice

Accountability should be assigned across three operational layers: cryptographic inventory ownership, certificate lifecycle management, and migration governance. Inventory owners are responsible for identifying where legacy RSA and ECC certificates exist, who depends on them, and whether each certificate is tied to a system that can be changed. Lifecycle owners manage issuance, renewal, rotation, revocation, and retirement. Governance owners decide what happens when a deadline is missed, including exception approval, escalation, and forced remediation.

This works best when the organisation treats certificates as managed assets with explicit control points, not as incidental configuration details. A practical model usually includes:

• Named business and technical owners for each certificate population.
• Automated discovery across servers, containers, appliances, and embedded systems.
• Deadline tracking for migration, renewal, and approved exceptions.
• Escalation paths that move overdue certificates from engineering to risk ownership.
• Evidence records showing who accepted residual risk and for how long.

The governance expectation is consistent with NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasises assignment, monitoring, and accountability for security-relevant activities. It also aligns with NHIMG guidance on machine identity management, especially where teams still rely on spreadsheets or manual tracking. The Ultimate Guide to NHIs is useful here because it frames certificates as part of a broader identity estate that needs ownership, not just renewal dates.

These controls tend to break down in organisations with federated infrastructure, inherited platforms, or unmanaged third-party appliances because no single team can see the full certificate footprint.

Common Variations and Edge Cases

Tighter migration enforcement often increases operational burden, requiring organisations to balance cryptographic risk reduction against system stability and dependency complexity. That tradeoff is real in legacy environments, where some RSA or ECC certificates cannot be removed quickly because vendor support, embedded firmware, or external partner integrations still require them.

Current guidance suggests that exceptions should be time-bound, documented, and owned by a named risk acceptor rather than left open-ended. Best practice is evolving around how to handle certificates that are technically valid but no longer compliant with migration policy. Some teams treat these as security exceptions; others classify them as technical debt with a fixed retirement plan. There is no universal standard for this yet, but the accountability model must be explicit either way.

Teams should also be careful not to confuse certificate expiry management with migration governance. A certificate can be renewed while still violating crypto policy, which means the renewal event may hide the real issue. Where asset ownership is ambiguous, NHIMG research shows the pattern repeats across machine identity programs: unclear ownership and poor visibility make audit and remediation harder than the actual technical change. That is why post-deadline RSA and ECC use should trigger escalation to the system owner, the security owner, and the designated migration owner, not remain with whichever team discovered it first.

If the question is whether “security” alone is accountable, the practical answer is no. Security should enforce policy, but platform, application, and service owners must own the certificates embedded in their systems.

Related resources from NHI Mgmt Group

• Who is accountable for hardening Active Directory compatibility settings when legacy defaults remain enabled?
• Who is accountable when SAP ECC continues operating past mainstream support with limited security patches?
• Who is accountable when deprecated Kubernetes ingress resources stay in production past a platform migration window?
• Who should own the migration from legacy endpoint deployment groups to profile-based management?