End-of-Support Migration Governance requires that organisations maintain continuous awareness of the support lifecycle status of every critical component in their AI agent stack — libraries, frameworks, runtime environments, operating systems, model serving infrastructure, and third-party services — and plan and execute migration to supported alternatives before any component reaches its end-of-support date. When a component loses vendor or community support, it ceases to receive security patches, bug fixes, and compatibility updates, creating a compounding vulnerability surface that grows with every passing day. This dimension mandates proactive migration planning with defined timelines, resource allocation, testing regimes, and rollback strategies, ensuring that no agent operates on unsupported infrastructure where a known vulnerability could persist indefinitely without remediation.
Scenario A — Unsupported Runtime Enables Unpatched Remote Code Execution: A financial-value agent performing automated trade reconciliation operates on a Python runtime environment that reached its official end-of-life 14 months prior. The organisation's engineering team was aware of the deprecation timeline but deferred migration due to competing feature development priorities. Nine months after end-of-life, a critical remote code execution vulnerability (CVSS 9.8) is discovered in the runtime's XML parsing module — a module the reconciliation agent uses to process incoming trade confirmations from 3 counterparties. Because the runtime is no longer supported, no patch is released. The organisation's security team identifies the vulnerability through a third-party advisory but has no remediation path other than full runtime migration — a project estimated at 6 weeks. During the 6-week migration window, the agent continues processing trade confirmations on the vulnerable runtime. An attacker exploits the vulnerability through a crafted XML payload embedded in a legitimate-looking trade confirmation, gaining execution context within the agent's environment. The attacker exfiltrates 47,000 trade records spanning 8 months. The resulting regulatory investigation reveals that the organisation knowingly operated critical financial infrastructure on unsupported software for 14 months.
What went wrong: The organisation had no enforced policy requiring migration before end-of-support. The deprecation timeline was known but treated as informational rather than mandatory. No migration plan was initiated during the 2-year deprecation window provided by the runtime vendor. The 6-week emergency migration under active exploitation was 14 months too late. Consequence: 47,000 trade records exfiltrated, regulatory fine of £2.3 million for operating critical infrastructure on unsupported software, 6 weeks of degraded operations during emergency migration, £890,000 in incident response and customer notification costs.
Scenario B — End-of-Life Model Serving Framework Breaks Compliance Chain: A customer-facing agent deployed across 4 EU member states uses a model serving framework whose maintainer announced end-of-support with a 12-month sunset period. The organisation acknowledged the announcement but classified the migration as a "Q4 initiative." Eight months into the sunset period, the framework maintainer releases a final security update and ceases all activity. The organisation has not begun migration. Four months after support ends, the EU AI Act conformity assessment process requires demonstration that all components in the AI system's supply chain receive ongoing security maintenance. The assessor identifies the unsupported framework and issues a non-conformance finding. The organisation cannot deploy new agent versions in the EU market until the framework is replaced. Migration takes 11 weeks. During the 11-week blackout, the customer-facing agent cannot be updated to address a separate bias detection issue identified by AG-037, because deploying any update would require recertification on the unsupported framework — which the assessor has already flagged.
What went wrong: The sunset period was treated as a soft deadline rather than a hard constraint. No migration plan was resourced during the 12-month window. The compliance dependency — that conformity assessment requires supported supply chain components — was not identified until the assessment itself. Consequence: 11-week deployment blackout across 4 EU markets, inability to remediate a bias issue during the blackout, estimated revenue impact of £1.7 million from delayed feature releases, conformity assessment failure requiring re-assessment at £180,000.
Scenario C — Cascading End-of-Support in Transitive Dependencies: A safety-critical agent controlling environmental monitoring sensors in a chemical processing facility depends on a data serialisation library (Library A) that itself depends on a cryptographic module (Library B). Library B reaches end-of-support. The organisation's SBOM tracking identifies Library B as a transitive dependency but the end-of-support monitoring covers only direct dependencies. Library A's maintainer releases an update that replaces Library B with a supported alternative, but the organisation does not apply the Library A update because their compatibility testing pipeline only flags direct dependency changes. Eleven months later, a vulnerability in the unsupported Library B allows an attacker to forge sensor data integrity signatures. The safety-critical agent processes forged sensor readings for 3 hours before anomaly detection triggers an alert. During those 3 hours, the facility operates with incorrect environmental readings. Post-incident analysis reveals that the Library B end-of-support was known in the open-source community for 18 months.
What went wrong: End-of-support monitoring covered only direct dependencies, not transitive dependencies. The SBOM identified Library B but its support lifecycle was not tracked. The Library A update that would have resolved the issue was not applied because the change appeared to be in a transitive dependency outside the monitoring scope. Consequence: 3 hours of forged sensor data in a safety-critical environment, facility shutdown for investigation costing £420,000 in lost production, regulatory investigation by the safety authority, £1.2 million in remediation including full dependency lifecycle monitoring implementation.
Scope: This dimension applies to every AI agent deployment that incorporates third-party components — whether commercial software, open-source libraries, runtime environments, operating systems, model serving infrastructure, cloud platform services, or any other component whose continued maintenance depends on an external party. The scope explicitly includes both direct dependencies (components the agent or its immediate infrastructure directly consumes) and transitive dependencies (components consumed by direct dependencies). If any component in the agent's dependency tree can reach an end-of-support state where security patches, bug fixes, or compatibility updates will no longer be provided, this dimension applies. The scope also covers components where "end-of-support" takes the form of maintainer abandonment (open-source projects with no active maintainers), vendor discontinuation (commercial products withdrawn from the market), or service deprecation (cloud services scheduled for retirement). Organisations that rely entirely on self-maintained, internally developed components with no external dependencies are exempt, though such configurations are vanishingly rare in practice.
4.1. A conforming system MUST maintain a continuously updated inventory of all third-party components (direct and transitive) in the AI agent's dependency tree, with each component's current support status, known end-of-support date (if announced), and estimated remaining support window (if no date is announced but health indicators suggest decline).
4.2. A conforming system MUST initiate a formal migration plan for any component no later than 60% of the way through its announced end-of-support timeline (e.g., if a component announces a 12-month sunset, the migration plan must be initiated by month 7), or within 30 days of an unscheduled end-of-support announcement with no sunset period.
4.3. A conforming system MUST ensure that no AI agent operates in production on any component that has passed its end-of-support date without an approved risk-acceptance exception signed by the designated risk owner, the security function, and — for safety-critical agents — the safety authority, with the exception subject to time-bounded renewal no longer than 90 days.
4.4. A conforming system MUST include in every migration plan: a target component or version, a tested migration path, a rollback procedure validated in a non-production environment, a resource allocation with named owners, milestone dates with defined completion criteria, and an impact assessment covering functional, performance, and compliance dimensions.
4.5. A conforming system MUST validate migration completeness by confirming that no instance of the end-of-support component remains in any production environment, staging environment, disaster recovery environment, or backup restoration path after the migration is declared complete.
4.6. A conforming system MUST monitor transitive dependencies for end-of-support conditions with the same rigour applied to direct dependencies, including automated detection of end-of-support announcements, maintainer abandonment signals, and upstream migration advisories.
4.7. A conforming system SHOULD maintain pre-validated migration paths for the top 10 highest-risk components (ranked by blast radius and replacement complexity), enabling rapid migration if an unscheduled end-of-support event occurs.
4.8. A conforming system SHOULD implement automated end-of-support horizon scanning that cross-references the component inventory against vendor lifecycle databases, open-source project health indicators per AG-490, and community advisory channels.
4.9. A conforming system MAY implement migration dry-run automation — the ability to execute a full migration in a production-mirror environment on a scheduled cadence (e.g., quarterly) to validate that the documented migration path remains viable as the codebase evolves.
Every software component has a lifecycle. Whether maintained by a commercial vendor with a published support matrix or by an open-source community with informal maintenance norms, every component will eventually reach a point where its maintainers stop providing updates. This is not a hypothetical risk — it is a certainty. The only questions are when it will happen and whether the organisation will be prepared.
The risk created by operating on unsupported components is not static; it compounds over time. On the day a component loses support, its vulnerability profile is identical to the day before — all previously patched vulnerabilities remain patched, and no new vulnerabilities are known. But from that day forward, every newly discovered vulnerability in that component will persist indefinitely. After 6 months without security patches, the probability of at least one exploitable vulnerability being present is substantially higher than at the moment support ended. After 12 months, it approaches near-certainty for widely used components. For AI agents processing sensitive financial data, making safety-critical decisions, or operating in regulated environments, this compounding risk is unacceptable.
The regulatory landscape reinforces this imperative. The EU AI Act Article 15 requires that high-risk AI systems are resilient and secure, which is incompatible with operating on components that cannot receive security updates. DORA Article 9 requires financial entities to maintain ICT systems that are "up to date" and "resilient" — unsupported software fails both criteria. The FCA's SYSC 6.1.1R requires firms to maintain adequate systems and controls; a system built on unsupported infrastructure cannot be considered adequate when the inability to patch is a known, foreseeable risk. SOX Section 404 requires effective internal controls over financial reporting; an AI agent processing financial data on an unsupported runtime represents a control deficiency that could escalate to a material weakness finding if the unsupported component is in the critical path.
The open-source dimension adds complexity. Commercial vendors typically provide clear end-of-support dates with multi-year notice. Open-source projects may lose support through maintainer burnout, project abandonment, or community fragmentation — events that rarely come with formal announcements. AG-490 addresses the health monitoring of upstream projects; AG-497 addresses what happens when that monitoring indicates impending or actual loss of support. The two dimensions work together: AG-490 provides the early warning, AG-497 mandates the response.
Migration is not merely a technical activity. It involves functional testing to ensure the replacement component provides equivalent capabilities, performance testing to ensure the replacement meets operational requirements, compliance testing to ensure the replacement does not introduce new regulatory risks (per AG-498 for upstream policy compatibility), and operational readiness including updated runbooks, monitoring configurations, and incident response procedures. Treating migration as a simple version upgrade underestimates the effort and leads to the deferred migrations illustrated in the scenarios above.
The 60% timeline trigger in Requirement 4.2 is based on empirical observation that migration projects typically require 40-60% of the available runway when properly planned, but expand to consume 100% or more when initiated late. Starting at the 60% mark provides adequate time for the migration itself while preserving a buffer for unexpected complications. Organisations that initiate migration at 90% of the sunset timeline routinely find themselves operating on unsupported components because the migration overruns the remaining window.
End-of-Support Migration Governance requires a combination of continuous monitoring, proactive planning, and disciplined execution. The core principle is that migration should be a planned, resourced activity completed before end-of-support — not an emergency response triggered by an incident or an audit finding.
Recommended patterns:
Anti-patterns to avoid:
Financial Services. Financial regulators have consistently intensified their scrutiny of technology lifecycle management. The PRA's supervisory expectations on operational resilience explicitly reference the need to maintain technology currency. Financial-value agents processing trade data, risk calculations, or regulatory reporting on unsupported components represent both a cybersecurity risk and a regulatory compliance failure. Firms should map end-of-support timelines against regulatory examination schedules to ensure that no unsupported components are present during examination periods.
Safety-Critical / CPS. For agents operating in safety-critical environments — industrial control, medical device integration, autonomous vehicle systems — the consequence of a vulnerability in an unsupported component extends beyond data loss to physical harm. Safety authorities may require that end-of-support migration for safety-critical agents be completed before the end-of-support date with no exception mechanism, as the risk of operating unsupported software in a safety-critical context may be unacceptable regardless of compensating controls. Migration plans for safety-critical agents should include safety case updates and may require re-certification.
Public Sector. Government agencies deploying AI agents face additional constraints: procurement cycles are longer, migration budgets require advance appropriation, and legacy systems often have deeply embedded dependencies on specific component versions. Public sector organisations should extend the planning horizon — initiating migration planning at 40% of the sunset timeline rather than 60% — to accommodate procurement and budgetary processes.
Basic Implementation — The organisation maintains an inventory of direct dependencies with known end-of-support dates. Migration plans are initiated when formal end-of-support announcements are made. No agent operates on unsupported components without a documented risk-acceptance exception. Migration plans include the minimum required elements: target component, migration path, and milestone dates. Migration completeness is verified for production environments.
Intermediate Implementation — All basic capabilities plus: transitive dependencies are tracked with lifecycle metadata. Automated horizon scanning detects approaching end-of-support from vendor lifecycle databases and project health indicators. Pre-validated migration runbooks exist for the top 10 highest-risk components. Parallel-run validation is used for all migrations affecting agents in the High-Risk/Critical tier. Migration completeness is verified across production, staging, disaster recovery, and backup restoration environments. A standing engineering allocation supports migration activities.
Advanced Implementation — All intermediate capabilities plus: migration dry-runs are executed quarterly in production-mirror environments. The component registry integrates with AG-490 project health signals to generate estimated support horizons for components without formal end-of-support announcements. Migration impact analysis automatically identifies all affected downstream components and generates dependency-aware migration sequencing plans. The organisation can demonstrate that no component in any agent's dependency tree has fewer than 12 months of remaining support without an active, resourced migration plan in progress.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Component Lifecycle Inventory Completeness
Test 8.2: Migration Plan Initiation Timeliness
Test 8.3: Unsupported Component Production Prohibition
Test 8.4: Migration Plan Completeness
Test 8.5: Migration Completeness Verification
Test 8.6: Transitive Dependency End-of-Support Detection
Test 8.7: Risk-Acceptance Exception Governance
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Supports compliance |
| EU AI Act | Article 15 (Accuracy, Robustness and Cybersecurity) | Direct requirement |
| SOX | Section 404 (Internal Controls Over Financial Reporting) | Supports compliance |
| FCA SYSC | 6.1.1R (Systems and Controls) | Direct requirement |
| NIST AI RMF | GOVERN 1.5, MANAGE 2.3 | Supports compliance |
| ISO 42001 | Clause 8.4 (Operation of AI Systems) | Supports compliance |
| DORA | Article 9 (ICT Risk Management Framework) | Direct requirement |
Article 15 requires that high-risk AI systems achieve an appropriate level of cybersecurity, including resilience against unauthorised third parties attempting to exploit system vulnerabilities. An AI agent operating on unsupported components with known, unpatched vulnerabilities cannot meet this requirement. The cybersecurity obligation is ongoing — it is not satisfied by the security posture at deployment time but must be maintained throughout the system's operational lifecycle. End-of-support migration governance is the mechanism that maintains cybersecurity posture as the supply chain evolves. Organisations deploying high-risk AI systems under the EU AI Act must be able to demonstrate that all components in the system's supply chain receive ongoing security maintenance, which is definitionally impossible for unsupported components.
For AI agents involved in financial reporting — generating financial data, processing transactions, calculating regulatory metrics, or producing audit evidence — operating on unsupported components represents a control deficiency. SOX auditors assess whether internal controls are designed and operating effectively. A control that depends on an unsupported component is not operating effectively because a known vulnerability could compromise the control's integrity at any time. The deficiency is particularly acute when the unsupported component is in the data processing path: if a vulnerability in an unsupported serialisation library could alter the data the agent processes, the integrity of the agent's financial outputs cannot be assured. AG-497 ensures that this control deficiency is prevented through proactive migration.
The FCA requires firms to maintain systems and controls that are adequate for the nature, scale, and complexity of their activities. Operating critical AI agent infrastructure on unsupported software is inadequate by definition — the firm has knowingly accepted a position where security vulnerabilities cannot be remediated. The FCA has issued supervisory letters explicitly referencing technology lifecycle management as a component of operational resilience. AG-497 provides the governance framework that ensures firms identify, plan for, and execute migrations before components become unsupported, maintaining the adequacy of systems and controls throughout the technology lifecycle.
GOVERN 1.5 addresses ongoing monitoring and periodic review of AI system risks. End-of-support transitions represent a foreseeable risk that must be monitored and managed. MANAGE 2.3 addresses the management of third-party risks in AI systems, including the risk that third-party components lose ongoing maintenance. AG-497 provides the specific controls for managing this third-party lifecycle risk within the broader NIST AI RMF governance structure.
DORA Article 9 requires financial entities to have a sound, comprehensive, and well-documented ICT risk management framework that includes strategies, policies, and procedures for the protection, prevention, detection, and response to ICT-related incidents. Operating on unsupported ICT components directly contradicts the "protection" and "prevention" requirements, as unsupported components cannot be protected against newly discovered vulnerabilities. DORA also requires that ICT systems are "kept up to date" — a requirement that cannot be met for unsupported components. Financial entities subject to DORA must implement AG-497 as part of their ICT risk management framework.
ISO 42001 requires that organisations manage the operational environment of AI systems, including the infrastructure and dependencies that support them. End-of-support migration governance ensures that the operational environment remains viable and secure throughout the AI system's lifecycle. Organisations pursuing ISO 42001 certification must demonstrate systematic management of component lifecycles, not merely snapshot compliance at the time of assessment.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | Component-scoped initially, but can cascade to all agents sharing the unsupported component — in worst cases, organisation-wide if the unsupported component is a shared runtime, framework, or platform service |
Consequence chain: A critical component reaches end-of-support without a completed migration. The immediate state is latent vulnerability — the component continues to function, creating a false sense of safety. Within weeks to months, a new vulnerability is discovered in the unsupported component. Because no patch is available, the vulnerability persists. If the vulnerability is publicly disclosed, the organisation faces a known, unpatched vulnerability in production — a condition that transforms a latent risk into an active exposure. Attackers scanning for known vulnerabilities in unsupported software identify the organisation's exposure. Exploitation follows, with consequences proportional to the agent's function: data exfiltration for data-processing agents, transaction manipulation for financial agents, safety system compromise for safety-critical agents. The regulatory investigation that follows the incident reveals that the organisation was aware of the end-of-support date, had not completed migration, and had no compensating controls adequate to address the risk. The regulatory finding — operating critical infrastructure on knowingly unsupported software — carries both direct penalties (fines, enforcement actions) and reputational consequences (loss of customer trust, increased scrutiny on future deployments). For safety-critical agents, the consequence chain extends to physical harm: a compromised environmental sensor, a manipulated control parameter, or a corrupted safety constraint can cause injury or loss of life. The compounding nature of the risk — growing worse every day the unsupported component remains in production — means that delayed migration is not a stable state but a deteriorating one.
Cross-references: AG-490 (Maintainer Trust and Project Health Governance) provides the upstream health monitoring that feeds early warning into AG-497's migration planning. AG-021 (Standards Versioning & Migration Governance) addresses versioning and migration at the governance standard level. AG-491 (Dependency Provenance and SBOM Attestation Governance) provides the dependency inventory foundation. AG-494 (Vendor Incident Disclosure Governance) addresses vendor transparency during support transitions. AG-496 (Escrow and Source-Access Governance) provides source access when vendors discontinue support. AG-498 (Upstream Policy Compatibility Governance) ensures replacement components are policy-compatible. AG-422 (Recovery Time Objective Governance) defines the recovery time constraints that migration plans must respect. AG-408 (Infrastructure Drift Detection Governance) detects when environments drift from the migrated state back to unsupported components.