2.5 Asset Retention, EOL & EOS
Asset Retention, EOL & EOS at a glance
Assets should not remain in an organisation indefinitely simply because they still function.
Hardware, software and services need to be reviewed throughout their lifecycle to determine whether they are still required, supported and appropriate for continued use.
Retain
Keep assets while there is a valid business or organisational reason.
Do we still NEED it?Support
Understand whether the technology continues to receive appropriate vendor support.
Can it still be MAINTAINED?Retire
Replace and securely remove assets when continued use is no longer appropriate.
How does it safely LEAVE?Asset retention lifecycle
1 What is Asset Retention? Keep an asset only while there is a valid reason to do so
Asset retention concerns decisions about how long an organisation should continue to maintain, store or operate an asset.
Assets may include:
Appropriate retention should consider whether the asset still provides sufficient value to justify the cost and risk of keeping it.
An application was created for a project that ended five years ago.
The application is still running because nobody has formally decided to retire it.
It still requires:
- patching;
- monitoring;
- access management;
- vulnerability management;
- infrastructure;
- support.
"Nobody has turned it off yet" is not a lifecycle strategy.
📦 Asset Retention vs Data Retention Related, but not the same question
How long should the hardware, software, application or service remain in use or under organisational control?
Think: Do we still need the ASSET?
How long should particular information remain before authorised disposition?
Think: Do we still need the INFORMATION?
An old payroll application is being retired.
The organisation may no longer need the application, but some payroll records may still need to be retained.
Retiring an asset does not necessarily mean destroying all of the data associated with it.Data-retention requirements were covered in CISSP objective 2.4.
2 Why retain an Asset? Continued existence should have a purpose
Assets may need to remain in operation or under organisational control for many legitimate reasons.
The asset continues to support an important business service.
Other systems or processes depend on the asset.
Requirements may affect preservation or availability.
Agreements may require continued service or support.
A replacement exists but migration is not yet complete.
Certain systems or artefacts may need temporary preservation.
The organisation should understand both the value of keeping an asset and the risk associated with continuing to operate it.
Asset Retention questions
Need. Support. Protect. Replace.
3 End of Life (EOL) The product is reaching or has reached the end of its lifecycle
End of Life is commonly used by technology vendors to describe a stage at which a product is reaching or has reached the end of its normal lifecycle.
However, the exact meaning of EOL is not universal.
One vendor may use EOL to mean that:
- a product is no longer actively developed;
- new sales have stopped;
- standard support will soon end;
- support has already ended;
- a formal retirement programme has begun.
Do not assume every manufacturer's use of "EOL" means exactly the same thing.
4 End of Support (EOS) Normal vendor support has ended or is ending
End of Support refers to the point at which the vendor or supporting party stops providing the normal support associated with the product.
Depending on the vendor and product, support can include:
A server operating system continues to boot and run its applications after the vendor's normal security support has ended.
A new vulnerability is later discovered.
The system may continue functioning while no normal vendor security update is available.The fact that technology still works does not mean it can still be maintained at an acceptable security level.
End of Sale vs EOL vs EOS
Vendor terminology varies, but the following model is useful for understanding the concepts.
| Term | General idea | Key question |
|---|---|---|
| End of Sale | The vendor stops selling the product. | Can we still buy it? |
| End of Life (EOL) | The product reaches or approaches the end of its vendor-defined lifecycle. | Is this product being retired? |
| End of Support (EOS) | Normal vendor support reaches its defined end. | Will the vendor still support and update it? |
| Decommissioned | The organisation removes its instance of the asset from service. | Have WE stopped using it? |
Some vendors use terms such as EOS, EOSL, EOL, retirement and discontinuation differently.
Always use the lifecycle dates and definitions published for the specific product.
EOL & EOS memory aid
Sold. Supported. Used. Retired.
The most important 2.5 memory
Still working ≠ still supported ≠ still secure.
📅 Term of Support How long will the technology be maintained?
Organisations should understand the expected support period of technology before and during its use.
Support may include:
- software and firmware updates;
- security fixes;
- vulnerability notifications;
- replacement parts;
- technical assistance;
- compatibility updates.
Organisation A buys a critical device expected to operate for 15 years.
The manufacturer guarantees normal support for only five years.
The mismatch between expected operational life and support life should be understood before the organisation becomes dependent on the technology.🛒 Consider EOL before Purchase Lifecycle management starts at acquisition
EOL and support risk should not first be considered when the vendor announces that support ends next month.
During acquisition, useful questions include:
A cheap product can become expensive if it requires emergency replacement shortly after deployment.
5 Risks of Unsupported Technology Why EOS matters to cybersecurity
Continued use of unsupported assets can create several types of risk.
Newly discovered vulnerabilities may no longer receive normal vendor fixes.
New applications, operating systems or security controls may stop supporting the old technology.
Modern endpoint, logging or security agents may no longer support the legacy platform.
Replacement parts may become difficult to obtain for old equipment.
Fewer employees or suppliers may understand obsolete technology.
Applicable security requirements may expect supported or appropriately maintained technology.
It means that an important layer of ongoing maintenance and assurance may no longer be available, increasing the need for explicit risk assessment and treatment.
6 Legacy Systems Old technology may still be business-critical
A legacy system is older technology that remains in use, often because an organisation still depends on the functionality or data it provides.
A manufacturing plant relies on a specialist control application written 20 years ago.
The application requires an operating system that is no longer normally supported.
Replacing it requires changes to physical industrial equipment.
"Upgrade immediately" may not be operationally possible, but ignoring the security risk is also inappropriate.Some legacy systems remain genuinely important. The organisation needs to understand and manage the resulting risk.
🏚️ Why do Organisations retain Legacy Systems? Replacement is not always simple
A hospital operates specialist diagnostic equipment whose vendor application works only with a particular legacy operating system.
Replacing the operating system could also require replacing expensive medical equipment and revalidating the environment.
The decision becomes a business and security risk decision rather than simply an IT upgrade.🧱 Technical Debt Postponed replacement can accumulate future cost and risk
Organisations may postpone upgrades or replacement because doing so appears cheaper or easier in the short term.
Over time, this can create technical debt.
Lifecycle planning can reduce the chance that predictable technology retirement becomes an emergency.
7 Track Lifecycle Status in the Asset Inventory Know which assets are approaching support deadlines
Asset-management information should provide enough lifecycle context to support proactive decisions.
Useful fields can include:
An organisation operates 300 database servers.
Asset records identify:
- 215 on fully supported versions;
- 60 approaching EOS within 12 months;
- 20 on extended support;
- 5 already unsupported.
🔎 Finding EOL Assets Lifecycle management depends on asset visibility
An organisation cannot manage EOL exposure if it cannot identify which technology it operates.
The concepts from CISSP objective 2.3 directly support EOL and EOS management.
8 Prioritising EOL Risk Not every unsupported asset creates identical risk
Organisations may have many legacy assets and limited resources for replacement.
Prioritisation should therefore consider risk and business context.
Greater exposure may increase the likelihood of attack.
Compromise may have greater confidentiality impact.
Failure may create severe operational impact.
Unresolved exploitable vulnerabilities can materially increase risk.
Architecture may affect available interim risk treatments.
Some legacy technologies have straightforward replacements while others require substantial redesign.
9 Compensating Controls for Legacy Assets Reduce risk when immediate replacement is not possible
Sometimes an unsupported asset cannot be replaced immediately.
The organisation may need additional controls to reduce exposure while migration occurs.
Restrict which systems and networks can communicate with the legacy asset.
Limit administrative and user access as far as practical.
Restrict execution to explicitly permitted software where appropriate.
Increase visibility of suspicious activity involving the asset.
Reduce exposed functionality where operationally possible.
Remove or restrict external connectivity where it is not required.
They do not make unsupported technology supported again.
They reduce particular risks while the organisation manages the underlying lifecycle problem.
✍️ Risk Acceptance Continued use should be a conscious decision
Where unsupported technology must continue operating, the residual risk should be understood and managed through the organisation's normal risk process.
A legacy system cannot be replaced for another 12 months.
Security identifies known limitations and recommends segmentation, enhanced monitoring and restricted administration.
Residual risk remains.
Appropriate business or risk ownership should decide whether that residual risk is acceptable while replacement proceeds.Security professionals identify and advise on risk. Appropriate organisational risk owners accept business risk.
10 Migration Planning Replace technology before the deadline becomes an emergency
Vendor lifecycle information can allow organisations to plan budgets, testing and migration well before support ends.
🔗 Understand Dependencies before Retirement Old systems rarely exist completely alone
Before decommissioning an asset, the organisation should understand what other assets or processes depend on it.
An old database appears unused and is scheduled for retirement.
Dependency analysis reveals that a monthly regulatory report still queries the database.
Turning it off without understanding that relationship could disrupt a business obligation.Dependency visibility helps prevent retirement from becoming an availability incident.
📦 Data during Asset Retirement The application may end while the information continues
Retirement planning should determine what happens to information stored or processed by the old asset.
A legacy HR application is retired.
Required employee records are migrated to the replacement system.
The organisation verifies the migrated records before sanitising the old storage.
Asset retirement and data destruction happen at different points in the process.11 Secure Asset Retirement Turning it off is only one step
Has the business confirmed the asset is no longer needed?
Will anything break when it is removed?
Has information that must remain been safely preserved?
Are application and administrative permissions no longer required?
Has the retired system been disconnected from operational networks?
Are identities associated solely with the retired asset still active?
Can unnecessary ongoing costs or entitlements be removed?
Has sensitive information been appropriately removed where required?
Does the asset record show its true lifecycle state?
What is the authorised final destination of the hardware or resource?
Retirement thinking flow
💻 Hardware EOL Physical equipment has a lifecycle too
Hardware lifecycle risk can involve more than software patching.
Older hardware may face:
A network appliance still performs its routing function correctly.
The manufacturer no longer produces security firmware updates or replacement components.
Its operational functionality has outlived its support lifecycle.💿 Software EOL Applications and dependencies can become unsupported
Software lifecycle management can apply to:
A modern web application runs on a supported operating system.
However, it depends on an obsolete software framework that no longer receives security fixes.
The supported operating system does not eliminate the risk created by the unsupported application dependency.Lifecycle risk can exist in dependencies beneath an application, not only in the most visible product.
☁️ Cloud and Service Retirement EOL is not limited to hardware you physically own
Cloud providers and other service vendors may retire:
A business application relies on Version 1 of an external API.
The provider announces that Version 1 will be retired in nine months.
The organisation needs to understand the dependency and migrate before the old interface becomes unavailable.The absence of physical hardware ownership does not remove lifecycle dependency risk.
🛟 Extended Support Sometimes support can continue beyond the standard lifecycle
Some vendors may offer additional paid or limited support after the normal support period.
It may provide additional time and risk reduction while the organisation migrates, but it should not automatically be treated as a permanent replacement for lifecycle planning.
A critical application cannot be migrated before standard vendor support ends.
The organisation purchases extended support for another year while completing the replacement programme.
Extended support can form part of a controlled transition strategy.🩹 Support is more than Patching Vendor support can provide several forms of assurance
Security patches are extremely important, but support can include more than vulnerability fixes.
Remediation for security defects.
Correction of reliability or functional problems.
Information about newly identified security weaknesses.
Expert support when operational issues occur.
Hardware components needed to maintain equipment.
Updates supporting newer surrounding technology.
🏦 Worked example: Unsupported Payment Server Apply EOL risk thinking
Server supporting a payment application.
Operating system has reached End of Support.
High — customer payments depend on the server.
The server communicates with several production systems.
Not possible because the payment application requires redesign.
Possible response
- record the lifecycle risk;
- restrict unnecessary network communication;
- reduce administrative access;
- increase monitoring;
- apply any legitimately available vendor support;
- establish a replacement programme;
- obtain appropriate acceptance of residual risk.
Segmentation and monitoring may reduce risk, but replacing or otherwise resolving the unsupported technology remains the underlying lifecycle issue.
🧹 Remove Redundant Assets Unused technology can still create attack surface
An asset does not need to be unsupported to become unnecessary.
A server was used during a migration project.
The migration completed two years ago, but the server remains active on the network.
It has:
- open network services;
- administrator accounts;
- installed software;
- potential vulnerabilities.
👤 Ownership and Lifecycle Decisions Someone must be accountable for retirement
Asset owners should understand important lifecycle changes affecting assets for which they are accountable.
Security identifies that a critical application platform reaches EOS next year.
Security may provide the risk information, but the relevant business and technology stakeholders need to plan and fund replacement.
Lifecycle management can require coordination between business owners, technology, security, procurement, finance and suppliers.
📊 Lifecycle Monitoring Make upcoming support deadlines visible
Mature asset-management processes can monitor upcoming lifecycle milestones rather than discovering them after support ends.
Useful reporting could include:
The organisation reports:
- 17 unsupported production assets;
- 42 reaching EOS within six months;
- 9 critical assets without funded migration plans;
- 3 unsupported assets exposed to the internet.
♻️ Final Disposal The asset lifecycle does not end when the power is switched off
When an asset leaves organisational use, the organisation should determine its authorised final disposition.
The asset may be appropriately sanitised, reconfigured and assigned to another authorised purpose.
Leased or supplier-owned equipment may be returned following appropriate data handling.
Equipment may enter an authorised recycling process after appropriate sanitisation.
Media may require destruction when that is the appropriate sanitisation outcome.
Asset disposal and data sanitisation should be coordinated.
Clear, Purge, Destroy and data remanence were covered in detail in CISSP objective 2.4.
⚠️ Common mistakes Asset lifecycle assumptions that create risk
Operational functionality does not tell you whether the asset remains supported, maintainable or appropriately secure.
Vendor lifecycle terminology varies. Always review the specific vendor's published definitions and dates.
A vendor may stop selling a product while continuing support for existing customers.
Unsupported systems may continue operating for years while their ability to receive normal fixes and support declines.
Not necessarily. Unsupported status changes the security and maintenance risk; the actual risk still depends on exposure, vulnerabilities, criticality and controls.
They may reduce particular risks but do not restore vendor maintenance or eliminate the underlying lifecycle issue.
Replacement decisions may involve operational, financial and business constraints. Security should identify risk and support appropriate treatment decisions.
Operating systems, applications, libraries, APIs, cloud services and other technology also have support lifecycles.
Extended support may reduce risk and provide migration time, but the underlying lifecycle transition usually still needs to be addressed.
Data may have independent retention requirements and may need to be migrated or archived.
Credentials, certificates, licences, inventory records, data, network configuration and physical media may still require action.
Replacement can require budgeting, redesign, testing, procurement and data migration. Planning should start before the deadline.
Supported technology may still be redundant or unnecessary and can create avoidable cost and attack surface.
Think lifecycle and risk — not simply "upgrade everything"
CISSP questions in this area often test whether you recognise the security implications of continuing to operate aging or unsupported assets.
Look for lifecycle-aware answers that consider business need, supportability, risk, migration and secure retirement.
⏳ Retention clues
📅 Lifecycle clues
⚠️ Risk clues
🛡️ Interim control clues
🔄 Migration clues
🚪 Retirement clues
When you see aging technology, ask:
Is it still needed? Is it supported? Can we still protect it? What is the migration plan? What happens when it leaves?
📝 Practice scenarios Apply asset lifecycle thinking
Scenario 1
A server operating system still functions correctly, but the vendor no longer provides normal security updates.
What is the key concern?
The system may continue functioning while its ability to receive vendor security maintenance has ended.
Scenario 2
A vendor stops selling a network appliance but continues supporting existing customers for another three years.
Has support necessarily ended?
No. End of Sale and End of Support are separate lifecycle events.
Scenario 3
An organisation sees the term "EOL" in a vendor announcement.
What should it do before assuming what this means?
Review the vendor's specific lifecycle policy and published dates, because terminology can vary between vendors.
Scenario 4
An unsupported industrial system cannot be replaced for another year.
What should happen?
Assess the risk, apply appropriate compensating controls, establish an authorised migration plan and manage residual risk through the organisation's risk process.
Scenario 5
Security isolates a legacy server from unnecessary network connections.
Is the server now supported?
No. Segmentation can reduce exposure but does not restore vendor support.
Scenario 6
A server has reached EOS but supports a critical customer service.
Should it simply be switched off immediately?
Not without understanding business dependencies and availability impact. The lifecycle risk should be managed while an appropriate replacement or other treatment is implemented.
Scenario 7
A supported server has not been used for two years but remains connected to production.
Should it necessarily remain?
No. Redundant assets should be reviewed because unnecessary systems can create unnecessary attack surface and management cost.
Scenario 8
An application is retired but regulatory records stored within it must remain available.
What should happen?
Required records should be migrated or preserved according to their retention requirements before the old asset is securely retired.
Scenario 9
A critical application reaches EOS in nine months.
When should migration planning begin?
Before the support deadline, allowing sufficient time to understand dependencies, select a replacement, test and migrate safely.
Scenario 10
The organisation's asset inventory records product names but no software versions or support status.
What problem does this create?
It becomes difficult to identify which assets are approaching or have already reached vendor lifecycle milestones.
Scenario 11
A business application uses a modern operating system but relies on an unsupported software framework.
Is the lifecycle problem solved because the operating system is supported?
No. Unsupported dependencies within the technology stack can still create security and maintenance risk.
Scenario 12
A cloud provider announces that an API version will be retired.
Does EOL management apply even though the organisation owns no hardware?
Yes. Services and APIs can create lifecycle dependencies just like physical technology.
Scenario 13
A legacy platform cannot be migrated before standard support ends, but the vendor offers one year of extended support.
How could this be used?
Extended support may provide additional transition time while a controlled replacement programme is completed.
Scenario 14
An old server has been powered off after migration.
Its administrative account and service certificate remain active.
Is retirement complete?
No. Associated access, credentials, certificates, inventory and data should also be addressed.
Scenario 15
A storage device from a retired server contains sensitive information.
What should happen before disposal or reuse?
Apply the organisation's appropriate media sanitisation process according to the sensitivity of the information and intended future use.
Scenario 16
A migration team plans to remove an old database because nobody uses its user interface.
A scheduled reporting process still queries it every month.
What was missing?
Adequate dependency analysis before retirement.
Asset Lifecycle memory aid
Acquire. Maintain. Replace. Retire.
Unsupported Asset memory aid
Control the risk. Fix the lifecycle problem.
Key takeaways
CISSP objective 2.5 requires ensuring appropriate asset retention, including End of Life and End of Support considerations.
Asset retention determines whether hardware, software, services or other technology should continue to remain in organisational use.
Asset retention and data retention are related but different.
An application may be retired while information previously stored within it still needs to be retained.
Assets should remain because there is a valid business or organisational requirement, not simply because nobody has removed them.
End of Life terminology varies between vendors.
Organisations should therefore consult the lifecycle definitions and dates associated with the specific technology rather than assuming every EOL announcement means exactly the same thing.
End of Support concerns the point at which normal vendor support reaches its defined end.
Support may include security updates, vulnerability notifications, technical support, bug fixes and replacement components.
Still working does not mean still supported.
Unsupported technology may continue operating while becoming more difficult to patch, maintain, monitor or integrate safely.
EOL and support periods should be considered during procurement rather than only when a product approaches retirement.
Asset inventories should contain sufficient version and lifecycle information to identify technology approaching EOL or EOS.
Lifecycle management depends on good asset visibility.
Legacy systems may remain because of genuine business, operational, financial or technical dependencies.
When immediate replacement is impossible, compensating controls may help reduce risk.
Those controls may include segmentation, restricted access, additional monitoring and reduction of unnecessary exposure.
Compensating controls reduce risk; they do not make unsupported technology supported again.
Residual risk from continued operation should be understood and managed through the organisation's normal risk process.
Migration should consider dependencies, testing, data transfer, validation and business continuity.
Retirement should address more than powering off the technology.
Credentials, certificates, network configuration, licences, data, inventory records and physical media may also need to be removed or updated.
Supported but redundant assets should also be reviewed because unnecessary technology can increase attack surface and management cost.
Most importantly: don't wait for unsupported technology to become an emergency — know the lifecycle, understand the dependency and plan the replacement before the deadline arrives.
📚 Sources & Further Reading Authoritative references
-
ISC2 — CISSP Certification Exam Outline
View official CISSP exam outline -
NIST Cybersecurity Framework 2.0
View NIST CSF 2.0 -
NIST CSF 2.0 Reference Tool — Asset Management
View NIST Asset Management outcomes -
NIST — Term of Support Glossary
View NIST definition -
NIST — Information System Life Cycle
View NIST definition -
NIST SP 800-88 Rev. 2 — Guidelines for Media Sanitization
View current NIST media-sanitisation guidance -
NIST NCCoE — Asset Management as a Foundation for OT Cybersecurity
View NIST project description