Replace Unsupported Software-Based Isolation Mechanisms Sharing Physical Resources
A software-based isolation mechanism is software that keeps separate workloads apart while they share the same underlying physical computing resources (the same processor, memory and storage). Common examples are a hypervisor (the software layer that runs several virtual machines on one physical server) and container software. This control requires that, when such an isolation mechanism shares physical computing resources, either the isolation mechanism itself or the operating system it runs on is replaced once the vendor (the company that made it) stops supporting it. "No longer supported" means the vendor no longer issues security patches, bug fixes or technical help, usually because the product has reached its end-of-life date.
Plain language
When you run several separated workloads on the same physical hardware, the software that keeps them apart (for example a hypervisor running virtual machines, or container software) is the only thing stopping one workload from reaching another. If that software, or the operating system underneath it, can no longer get security updates from its maker, a flaw that lets one workload break into another may never be fixed. This control says: once the vendor stops supporting that isolation software or its operating system, replace it with a supported version or product. Do not keep relying on isolation software that can no longer be patched, because attackers actively hunt for known, unfixed weaknesses in end-of-life software.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
June 2026
Control Stack last updated
18 June 2026
E8 maturity levels
N/A
Guideline
Guidelines for system hardeningSection
Virtualisation HardeningOfficial control statement
When using a software-based isolation mechanism that consumes shared physical computing resources, the isolation mechanism or underlying operating system is replaced when it is no longer supported by a vendor.
Why it matters
If isolation software sharing physical hardware loses vendor support, unpatched flaws can let one workload break into another, exposing data on the same host.
Operational notes
Track vendor support dates for each isolation mechanism and its operating system, and replace either one before support ends so shared-resource separation stays patchable.
Implementation tips
- IT or platform team keeps a register of every software-based isolation mechanism (hypervisors, container platforms) and the underlying operating system each one runs on, recording the vendor and the published end-of-support date for each.
- IT team subscribes to vendor support and end-of-life notices for each isolation mechanism and its operating system, so loss of support is known well before it happens rather than discovered after the fact.
- System or change manager prepares a replacement plan for each mechanism that reaches end-of-support, covering whether the isolation mechanism, the underlying operating system, or both are being replaced, plus timeline, budget and rollback steps.
- Procurement manager negotiates support and licensing terms that align renewal dates with the organisation's replacement schedule, so isolation software does not silently fall out of support between renewals.
- Security officer sets a rule that no software-based isolation mechanism sharing physical resources may remain in production past its vendor support date, and confirms each replacement is completed and verified before the old version is decommissioned.
Audit / evidence tips
- AskWhich software-based isolation mechanisms that share physical computing resources do you run, and what are the vendor support end dates for each one and its underlying operating system?Look ata current register of hypervisors and container platforms with vendor names and end-of-support datesGoodevery shared-resource isolation mechanism is listed with a known, in-date support status, and none are past end-of-support in production
- AskHow do you find out when a vendor is ending support for an isolation mechanism or its operating system?Look atvendor end-of-life notices, subscription confirmations or support contractsGooddocumented vendor notifications received ahead of the support end date, not after
- AskShow me a case where an isolation mechanism or its operating system reached end-of-support and was replacedLook ata replacement plan and completion record showing what was replaced, when, and that it now runs supported softwareGooda completed replacement with the unsupported version removed and the new version confirmed supported
- AskIs anything providing isolation across shared physical resources currently running on an unsupported version?Look atthe register cross-checked against live systems and patch recordsGoodno unsupported isolation mechanism or underlying operating system is in production, with evidence the register matches reality
- AskWhat stops an unsupported isolation mechanism from being left in service?Look ata policy or standard setting end-of-support replacement requirements and named ownersGooda clear rule that unsupported shared-resource isolation software must be replaced, with assigned responsibility and recent reviews
Cross-framework mappings
How ISM-1848 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
handshakeSupports(1)expand_less | ||
| Annex A 8.8 | ISM-1848 demands replacement of unsupported server isolation or OS components to avoid vulnerabilities | |
E8
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(3)expand_less | ||
| E8-PO-ML1.8 | ISM-1848 requires that unsupported server isolation mechanisms or OS are replaced to maintain security | |
| E8-PA-ML1.9 | ISM-1848 requires replacing an isolation mechanism or underlying OS when vendor support ends, ensuring server security | |
| E8-PO-ML3.9 | E8-PO-ML3.9 requires organisations to use the latest or previous OS release | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in System hardening
See all Guidelines for system hardening controls, or browse the full ASD ISM library.