PCI DSS end-of-life systems: what assessors expect

How PCI DSS treats end-of-life systems in the cardholder data environment

When an operating system or product in the cardholder data environment (CDE) reaches vendor end of life, it can no longer receive the security patches PCI DSS expects, so the organization can keep it only through temporary compensating controls while it runs an active migration plan. The organization owns that decision and the migration. An implementation partner can prepare systems, configuration records and evidence, but only the QSA issues the Report on Compliance and only the ASV issues scan results.

Cost, timeline and assessor outcome depend on three factors. The first is exposure: a system that is Internet-facing is reported as an automatic failure in an ASV scan under PCI SSC FAQ 1130, and must be handled under the ASV Program Guide's section on compensating controls. The second is how many systems are affected, since each one needs its own controls and its own migration path. The third is how mature the technology review under Requirement 12.3.4 is. That requirement expects hardware and software to be reviewed at least every 12 months, including vendor end-of-life announcements and a remediation plan approved by senior management. Confirm with your QSA whether your current review would satisfy this on its own.

Before the assessment, ask your team to produce three things: a current software and component inventory (now required under Requirement 6.3.2), a list of each unsupported system with its isolation and monitoring controls, and a dated migration plan with a named owner and senior-management approval. Missed periodic activities cannot be backdated or covered by compensating controls, so a review that lapsed before the assessment must be corrected and performed successfully before the assessor can find the requirement in place.

How PCI DSS end-of-life systems move from discovery to assessor sign-off

This sequence turns an unsupported system from an unnoticed risk into a documented, monitored and funded migration that a QSA can test, with each step leaving a record the assessor can examine.

Build the software and component inventory
Start by listing every operating system, middleware, database, library and application in scope, with version, vendor, host and owner. Requirement 6.3.2 expects this inventory to be maintained for vulnerability and patch management, and it became a required practice on 31 March 2025 after being a best practice before that date. Your team owns the inventory, and a provider can help automate discovery. Done means every in-scope component has a record your assessor can sample against the network diagram and asset list.
Identify end-of-life announcements in the 12-month review
Compare each inventory entry against vendor support and end-of-life announcements during the review of hardware and software technologies that Requirement 12.3.4 requires at least every 12 months. The review covers vendor end-of-life announcements and produces a dated record of what is approaching or past support. Confirm the exact support dates with each vendor in writing, since this page does not supply them. Done means a signed review record lists each affected component and its support status.
Assess the risk of each unsupported component
For each component past support, document what it does, what data or systems it touches, how exposed it is, and which vulnerabilities would no longer receive vendor patches. Consider whether it sits inside the cardholder data environment and whether it can be reached from the Internet. The output is a risk assessment worksheet per component, approved by the people accountable for the affected system. Done means each unsupported component has a documented rationale for the risk level it carries.
Design and document compensating controls
Where a system cannot yet be replaced, design temporary compensating controls that address the risk the missing patches leave open. Isolation, application allow-listing and active monitoring are the examples the PCI SSC gives for unsupported operating systems. Record each control on a compensating control worksheet that states the constraint, the objective, the controls and how they were tested. These controls are temporary, and they do not replace the migration. Done means each control has a worksheet and an owner who can show it operating.
Handle Internet-facing systems in ASV scans
If an unsupported operating system is Internet-facing, the ASV scan reports it as an automatic failure. The PCI SSC directs that such a finding be handled under the ASV Program Guide section on addressing vulnerabilities with compensating controls. Ask your ASV which evidence it needs and how the rescan will be handled. The output is the scan report and the rescan result that accompany your compensating control record. Done means the ASV has accepted the handling route in writing before you rely on it.
Approve a senior-management migration plan
Write a migration plan that names each unsupported component, its replacement or upgrade path, the responsible owner, the dependencies and the milestones. Requirement 12.3.4 expects the remediation plan to be approved by senior management, so the approval must be recorded with names and dates. Ask your implementation partner to estimate effort and sequencing in a written proposal, and ask your QSA how they will test progress. Done means a signed plan exists and every compensating control points to a migration milestone.
Test the controls and plan with the assessor
During the assessment, the QSA samples the inventory, review record, risk worksheets, compensating control evidence, ASV reports and approved plan, and checks that the controls operate as described. Periodic activities that were missed cannot be backdated or covered by a compensating control, so keep the review cycle current. Ask your QSA which samples they will take and what evidence they expect before the assessment starts. Done means the assessor has tested the evidence set and recorded the outcome in the report on compliance.

What makes end-of-life remediation cost more or take longer

Remediation effort for an unsupported system depends less on the patch itself than on what surrounds it: where the system sits, what depends on it, and how well the organization already documents it. The six drivers below are the points where scope tends to grow, so checking them early shapes both the budget and the timeline.

Number and location of unsupported systems

Each unsupported operating system or product inside the cardholder data environment adds a migration path, a compensating control and evidence that an assessor will sample. Count the systems by segment, not only by host name, because a single retired image often repeats across a fleet. Ask which systems are in scope for each payment channel and which sit in shared management networks. Consolidating duplicates onto one target build before planning usually reduces the number of separate migrations.

Internet-facing exposure

An unsupported operating system reachable from the Internet is reported as an automatic failure in an ASV scan, so it moves to the front of the queue. Confirm which external addresses and published services resolve to these hosts, including forgotten test servers and legacy redirects. Isolating or removing public exposure early is often the cheapest step, because it changes the risk profile before any upgrade is scheduled.

Application dependencies that block upgrades

Many end-of-life systems persist because a vendor application, licensed driver or payment integration only runs on the old platform. Each such dependency turns an operating system upgrade into an application project with testing, vendor coordination and possibly new licensing. Map which applications run on each host and which versions they require before choosing a target platform. Where a dependency has no supported path, record it in the migration plan with a named owner and a decision date.

Third-party and vendor-managed components

When a vendor operates a terminal, appliance or hosted component that runs an unsupported product, your organization often cannot patch or upgrade it directly. Remediation then depends on contract terms, vendor roadmaps and responsibility matrices that may be vague about end-of-life support. Request written end-of-life dates and upgrade commitments from each vendor early. Treat a missing answer as a risk item for the 12.3.4 review rather than assuming the vendor will handle it.

Maturity of the software inventory

Remediation cannot be scoped reliably without a current inventory of hardware and software, including versions and support dates. Where the inventory is built by hand or spread across spreadsheets, teams spend the first phase rediscovering systems instead of migrating them. Confirm that the inventory records operating system, product version, owner and location for every component in scope. A maintained inventory also gives assessors the evidence they will request under the technology review.

Evidence behind existing compensating controls

Compensating controls such as isolation, allow-listing and monitoring can carry an unsupported system through the migration period, but only if they are documented and operating. Where the worksheet, configuration records and monitoring alerts are incomplete, each assessment cycle becomes a rebuild of the argument. Check that every compensating control has a current description, a test record and a link to the specific system it covers. Strong evidence keeps the interim period short in effort and avoids disputes with the assessor.

Who owns the migration, who prepares the evidence and who judges it

Your organization remains accountable for every system in the cardholder data environment, including systems that have lost vendor support. PCI DSS places the annual technology review and the remediation plan with the entity, and no partner or assessor can accept that risk on your behalf. Leadership decides whether an unsupported system stays in place, under which compensating controls and for how long.

Risk decision: Record in writing whether an end-of-life system is retained temporarily, isolated or retired, and name the person who approved it.
Plan approval: Obtain senior-management approval of the migration plan, which Requirement 12.3.4 expects as part of the review of hardware and software technologies at least every 12 months.
Inventory currency: Keep the software and component inventory current, since Requirement 6.3.2 is now required and an out-of-date inventory undermines every patching and vulnerability record.
Migration and production change: Own cutover approval, testing, rollback and change records for any change to in-scope systems.
Daily operation of controls: Run the isolation, allow-listing and monitoring that serve as compensating controls, because a control that is not operated will not survive sampling.

Before the assessor's first sample request, confirm that each item has a named owner, a date in the risk register and a signed approval on file.

What end-of-life remediation costs and who gets paid for each part

This table separates the cost lines that usually appear when an unsupported operating system or product is handled under PCI DSS, showing who is paid, whether each line is one-time or recurring, and what drives it. No supplied figures exist for these lines, so read the table as a checklist for requesting written quotes, not as a price estimate. The main takeaway is that the assessor and the ASV are paid for independent validation, while remediation, replacement and compensating control tooling are separate lines that you should price individually.

Cost component	Who is paid	One-time or recurring	What drives it
QSA assessment fee	Qualified Security Assessor firm, for the ROC or validation work	Recurring, each assessment cycle	Scope size, number of systems in the CDE, sampling depth, and how much unsupported-system evidence the assessor must review
ASV scan service for Internet-facing systems	Approved Scanning Vendor	Recurring, usually each scan cycle	Number of Internet-facing IP addresses, scan frequency, and rescans needed after an automatic failure on an unsupported OS
Implementation partner for isolation, migration or evidence work	Implementation partner under a written, fixed-scope agreement	One-time for the project, with possible follow-on support	Number of unsupported hosts, complexity of network segmentation, migration target, and how much documentation is required
Replacement software, hardware or vendor extended support	Software vendor, hardware vendor or cloud provider	One-time for replacement, recurring for extended support contracts	Whether the vendor offers paid extended support, license model, hardware refresh cycle, and contract term
Internal staff time for testing and business sign-off	Your own employees (internal cost, not an invoice)	One-time for migration testing, recurring for the annual technology review	Application dependencies, change windows, number of business owners who must approve the remediation plan
Compensating control tooling such as monitoring or allow-listing	Tool vendor, managed service provider or implementation partner	Often recurring (licenses, subscriptions, monitoring)	Number of endpoints, log volume, whether monitoring is 24/7 or business hours, and whether allow-listing is managed in-house

Why compensating controls for end-of-life systems are a temporary bridge

Compensating controls keep an unsupported system in scope as a temporary bridge, not a permanent fix. PCI SSC FAQ 1130 explains that an operating system no longer supported by its vendor cannot receive the security patches the standard expects, but controls such as isolation, application allow-listing and active monitoring may address the risk for a limited period. That allowance depends on the entity keeping an active plan to migrate to a supported system. If the plan lapses, or the system stays in place with no visible progress, the control no longer bridges anything and the assessor will treat the gap as open. Before relying on any control, confirm with your assessor which controls they expect to see for your specific operating system and how long they will accept the arrangement.

The assessor, not your organization or your implementation partner, decides whether a compensating control is sufficient. Your team can propose the control, test it and document it, but the QSA judges whether it meets the intent of the requirement it replaces. Each control must be written up on the compensating control worksheet, which records the constraint, the objective of the original requirement, the risk it introduces, the controls that address that risk and how they were validated. Treat the worksheet as the evidence file: vague descriptions such as "network isolation in place" rarely survive review, while specific segmentation rules, allow-list exports and monitoring alert records do.

Missed periodic activities cannot be backdated or compensated. PCI SSC FAQ 1572 makes clear that if a recurring task, such as the 12-month technology review required by Requirement 12.3.4, was not performed before an assessment, the assessor cannot accept a compensating control to cover the gap. The requirement is treated as in place only after corrective action is taken and the activity is performed successfully. For end-of-life systems, this means the annual review that identifies the vendor end-of-life announcement and records a senior-management-approved remediation plan must happen on schedule. Confirm your review calendar now, because a missed cycle cannot be repaired retroactively.

Upgrade, isolate or retire: choosing the path for an unsupported system

This table compares the four paths an organization can take when an operating system or product in the cardholder data environment loses vendor support. Read each row against the evidence column, since the assessor will ask whether the record proves the chosen path. The main takeaway is that isolation is a temporary bridge with its own evidence burden, while upgrade, replacement or removal from scope are the outcomes an assessor expects to see over time.

Option	When it fits	Evidence it creates
Upgrade to a supported version	The application runs on a supported operating system or product version, and testing confirms it	Change record, test results and the new patch baseline in the inventory
Replace the product or service	The vendor no longer supports the product at all, or no supported version runs the application	Migration plan approved by senior management, cutover records and decommission record
Isolate with compensating controls while migrating	A temporary bridge only, while a dated migration plan is active and the business cannot yet upgrade or replace	Compensating controls worksheet, segmentation evidence and monitoring records showing the controls operate
Retire or remove from scope	Data flows can be redirected or the system is no longer needed, so it leaves the cardholder data environment	Updated scope statement, network and data-flow diagrams, and records showing card data was removed

How to choose an assessor or implementation partner for end-of-life work

Systems past end of life create PCI DSS work that usually involves two different parties: a partner that changes systems and an assessor that judges the result. The four checks below help you confirm who is qualified, keep the roles separate, and agree on what will be delivered and how the work will be evidenced.

Confirm assessor and ASV status

Before engaging anyone, confirm with the PCI Security Standards Council that the firm and the individuals are listed as a Qualified Security Assessor company, and that any scanning vendor is an Approved Scanning Vendor. Ask for the listing reference and check it yourself rather than relying on a copy from the firm. For unsupported internet-facing systems, an ASV scan can report an automatic failure, so the scanning vendor's status matters as much as the assessor's. Ask: which PCI SSC listing covers the people who will sign off on this work?

Separate design from judgment

The firm that designs the migration or the compensating controls should not also be the one that judges whether they are sufficient. PCI SSC guidance on QSA independence sets out when a single firm can perform both roles. Map who does each task in your plan: the partner builds, your team owns the decisions, and the QSA validates. If one firm would both design and assess the same control, ask how independence is maintained and what the assessor will document about it. Ask: which firm will assess the controls this partner builds, and what independence rules apply?

Require a fixed written scope

A written scope should list each unsupported system by name, the work to be done on it, the deliverables, and the date each deliverable is handed over. It should also state what is excluded, such as application code owned by a third party or systems the partner does not administer. Fixed-scope agreements make it clear which parts of the migration are paid for and what happens if a system is found to be out of scope. No partner can guarantee that an assessor will accept the outcome, so the scope should describe the work and the evidence, not a result. Ask: which systems, deliverables and evidence files are named in the signed scope?

Plan how the work is evidenced

Assessors test end-of-life work through records: the hardware and software review, the senior-management-approved remediation plan, the software inventory, patch and vulnerability records, and the documented compensating control worksheets. Ask the partner how each of these will be produced, where they will be stored, who in your organization owns them, and how they will be handed over at the end of the engagement. Ask for a sample of the evidence pack before work starts. Ask: what evidence will the partner produce for each system, and in what format will your team keep it?

What patching expectations change in PCI DSS v4.0.1

The most important change for an unsupported system is that the one-month installation timeframe now applies only to critical vulnerability patches. PCI DSS v4.0.1 reverted Requirement 6.3.3 so that other security patches are installed within a timeframe the entity determines itself. That flexibility is useful, but it does not reduce the expectation that patches are applied. For a component whose vendor has stopped issuing patches, there is nothing to install, so the question an assessor asks shifts from how fast patches went in to whether the entity can show the risk is controlled and the system is leaving service. Confirm with your QSA how they read the timeframe you set for non-critical patches, and document the basis for it.

Requirement 6.3.2, the software and component inventory, is now mandatory, and it is the practical starting point for this work. You cannot judge whether a component is end of life, or whether it is Internet-facing, without an inventory that lists operating systems, middleware, libraries and appliances along with their versions and owners. Build the inventory from configuration management data, package managers and asset records, then compare each entry against vendor support dates. Requirement 12.3.4 adds a 12-month review of hardware and software technologies, including vendor end-of-life announcements, so the inventory should record the support end date for every entry.

An unsupported component cannot receive vendor patches, so the patching expectation is met only through compensating controls and a funded migration plan, both documented and both approved by senior management. Expect your assessor to look for the specific controls that limit exposure, such as network isolation, application allow-listing and active monitoring, and for evidence that they operate. Ask your QSA whether a compensating control worksheet is needed for each affected system and how the migration date will be judged. Treat any missed patching activity on a supported component as a separate matter, because it cannot be backdated or covered by a compensating control.

What assessors look for before they accept an end-of-life system

Assessors do not accept an unsupported system on the strength of a promise to replace it. They look for a chain of records that starts with an accurate inventory, shows a dated review of vendor lifecycle status, documents the temporary controls, and ends in an approved migration plan. Check each link before the assessment begins.

Current inventory of operating systems and software

Assessors start by asking which operating systems and software products run in the cardholder data environment and which version each one runs. The inventory must list every component, including virtual machines, appliances, embedded systems and middleware, with its version and owner. Check it against a live discovery scan rather than the last spreadsheet, because a system missing from the inventory cannot be assessed for end-of-life status. Confirm that the inventory is maintained as part of routine patch and vulnerability management.

Dated technology review under 12.3.4

Requirement 12.3.4 expects hardware and software technologies to be reviewed at least every 12 months, including vendor end-of-life announcements. The assessor will ask for the most recent review record, its date, who performed it and which vendor notices it considered. Confirm that the record names each end-of-life product found in the inventory and that a senior manager approved the remediation plan. A review that is undated or older than 12 months will not satisfy the assessor.

Compensating control worksheet per system

Each unsupported system needs its own completed compensating control worksheet that explains the constraint, the objective it meets and the controls in place, such as isolation, allow-listing and active monitoring. Assessors test whether the controls work, so ask for evidence such as allow-list exports, segmentation test results and monitoring alerts. Confirm that the worksheet is reviewed and signed off by the people accountable for the system. A generic template applied to every system usually fails because the risk differs between systems.

Migration plan with owners and milestones

Compensating controls are temporary, so assessors expect an active plan to move each system to a supported platform. The plan should name an accountable owner for each system, set milestones with dates, and show senior management approval. Confirm that the milestones are realistic for the system's dependencies, such as application certification or hardware procurement, and that progress is recorded against them. A plan with no dates or no named owner signals that the exception is open-ended.

ASV scan results and documented handling

An Internet-facing unsupported operating system is reported as an automatic failure in an ASV scan. Before the assessment, run or obtain a scan result for every externally reachable address and identify any unsupported system it reports. For each one, confirm that the handling follows the ASV Program Guide's approach to vulnerabilities addressed with compensating controls, and that the documentation explains the controls and the migration plan. Ask your ASV which findings will be reported as failures before the assessor does.

Questions buyers ask about end-of-life systems and PCI DSS

Is an unsupported operating system automatically non-compliant with PCI DSS?

No, an unsupported system is not automatically non-compliant, but the risk has to be handled deliberately. Per PCI SSC FAQ 1130, an operating system that no longer receives vendor security patches cannot meet the patching expectations as written, so the entity needs compensating controls and an active plan to migrate. The critical exception is Internet-facing systems: an unsupported Internet-facing operating system is reported as an automatic failure in an ASV scan and must be handled under the ASV Program Guide's section on compensating controls. Confirm with your QSA how the finding will be recorded in your environment before the scan.

How long can a compensating control cover an end-of-life system?

The facts do not set a fixed duration, so ask your QSA to state what they will accept for your system and risk profile. A compensating control is meant as a temporary measure, such as isolation, application allow-listing and active monitoring, while the entity keeps a live migration plan. Assessors look for that plan being active and progressing, not for a date that says when the control expires. Put the timeline, the owner and the approval for each milestone in writing so the assessor can test it.

Can our own team migrate the end-of-life systems without outside help?

Yes, an internal team can run the migration, provided it has the skills and capacity for the work. Before starting, assess whether the people involved know the target platform, the application dependencies and the change process well enough to test and roll back. Requirement 12.3.4 expects technology reviews at least every 12 months and a remediation plan approved by senior management, so the team needs to produce those artifacts regardless of who does the engineering. Many organizations keep the plan and approvals in-house and bring in a partner only for the parts they lack capacity or skills to deliver.

What does a migration project need from internal staff?

A migration needs named owners in several roles, and internal staff usually hold most of them. The system owner must confirm which cardholder data flows through each component, the application team must validate functionality on the new platform, and security must keep the software and component inventory current, which is a required item under Requirement 6.3.2. Change management must approve each cutover, and operations must keep backups and rollback paths ready. Ask any implementation partner to list these roles in the written scope so no owner is assumed.

What drives the cost of migrating or isolating end-of-life systems?

The main cost drivers are the number of affected systems, how many applications depend on each one, and how much of the environment sits inside cardholder data scope. Other factors include the complexity of the compensating controls, such as network isolation or allow-listing, and whether the new platform needs hardware, licenses or cloud resources. Ongoing costs include monitoring and the annual technology review. No price is set by the standard, so ask any provider or assessor for a quote built from a written scope that lists systems, controls, deliverables and timelines. Assessment fees are separate from implementation work and should be quoted separately.

Can an implementation partner issue the evidence sign-off for end-of-life controls?

No, an implementation partner cannot issue the sign-off. A partner can prepare systems, configuration evidence, inventories, compensating control records and the migration plan, but only the QSA issues the Report on Compliance and only an ASV issues scan results. The organization owns its controls and decides what to submit. Keep the partner's delivery documents separate from the assessor's conclusions, and confirm with your QSA which evidence they need before work begins. Assessor independence rules apply, so check how the engagement is structured before engaging both.

Can a missed patch cycle or review be fixed retroactively for the assessment?

No, a missed periodic activity cannot be backdated, and a compensating control cannot cover it. Per PCI SSC FAQ 1572, the assessor can find the requirement in place only after corrective action is taken and the activity has been performed successfully. In practice, that means completing the missed review or patch cycle now, documenting the corrective action and keeping evidence of the new cycle running on schedule. Build recurring reminders and ownership for the annual technology review so gaps do not reach the assessment.

How DeployOpen scopes and prepares end-of-life migrations for assessment

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so systems leaving vendor support can be replaced with supported, evidenced alternatives. We prepare the systems, controls and evidence for your assessment, while your organization owns its controls and an independent QSA issues the ROC and AOC.

How we scope

Inventory every operating system and software product in the cardholder data environment, including vendor end-of-life dates you confirm with each vendor.
Map which end-of-life components are Internet-facing, since those affect ASV scan results and need a defined handling path.
Agree the migration scope, deliverables and timelines in writing before any work starts, as most engagements are fixed-scope.

How we build

Plan and deploy supported replacement platforms in your cloud accounts, data centers or air-gapped networks, with hardening documented for each component.
Set up a software and component inventory and a patch workflow that records installation timeframes your team has approved.
Put interim compensating controls such as network isolation, allow-listing and monitoring in place, documented on worksheets for your assessor to review.

How we hand over

Deliver a dated migration plan and the evidence an assessor samples, including change records, configuration baselines and test results.
Document the annual technology review and the senior-management-approved remediation plan so your team can repeat them without us.
Provide a handover session and written runbooks, and confirm with your QSA which evidence they need before the assessment begins.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial migration is delivered.
Retainers can cover recurring tasks such as the 12-month technology review, inventory updates and rescans of remediated systems.
Ask any provider to confirm in writing which parts of the work are their responsibility and which remain with your team and assessor.