ASD ISM 1848 Replace unsupported software-based isolation mechanisms sharing physical resources
What it says
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.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishA 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.
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.
Free. Save your status, tasks and notes.
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.
How to implement
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.
Keep it running
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.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Which 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 at
a current register of hypervisors and container platforms with vendor names and end-of-support dates.
Good evidence
every shared-resource isolation mechanism is listed with a known, in-date support status, and none are past end-of-support in production.
- Check 2 of 5What an auditor asks for
Ask for
How do you find out when a vendor is ending support for an isolation mechanism or its operating system?
Look at
vendor end-of-life notices, subscription confirmations or support contracts.
Good evidence
documented vendor notifications received ahead of the support end date, not after.
- Check 3 of 5What an auditor asks for
Ask for
Show me a case where an isolation mechanism or its operating system reached end-of-support and was replaced.
Look at
a replacement plan and completion record showing what was replaced, when, and that it now runs supported software.
Good evidence
a completed replacement with the unsupported version removed and the new version confirmed supported.
- Check 4 of 5What an auditor asks for
Ask for
Is anything providing isolation across shared physical resources currently running on an unsupported version?
Look at
the register cross-checked against live systems and patch records.
Good evidence
no unsupported isolation mechanism or underlying operating system is in production, with evidence the register matches reality.
- Check 5 of 5What an auditor asks for
Ask for
What stops an unsupported isolation mechanism from being left in service?
Look at
a policy or standard setting end-of-support replacement requirements and named owners.
Good evidence
a clear rule that unsupported shared-resource isolation software must be replaced, with assigned responsibility and recent reviews.
Mappings
Closest match in ISO/IEC 27001: A.8.8, Management of technical vulnerabilities, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.8.
ISM-1848 demands replacement of unsupported server isolation or OS components to avoid vulnerabilities. Annex A 8.8 underpins this requirement by mandating measures for known vulnerabilities management, which can include replacement when patches are unavailable.
ASD Essential Eight: 3 mappings
This control partially overlaps E8-PA-ML1.9.
ISM-1848 requires replacing an isolation mechanism or underlying OS when vendor support ends, ensuring server security. E8-PA-ML1.9 deals with the end-of-life risk management for end-user and security software, highlighting a shared concern about unsupported software, though in different contexts.
This control partially overlaps E8-PO-ML1.8.
ISM-1848 requires that unsupported server isolation mechanisms or OS are replaced to maintain security. E8-PO-ML1.8 also mandates replacing unsupported operating systems, creating a direct overlap regarding end-of-support software replacements. Both controls focus on maintaining system integrity, albeit with different scopes.
This control partially overlaps E8-PO-ML3.9.
E8-PO-ML3.9 requires organisations to use the latest or previous OS release. ISM-1848 requires that, in virtualised/server isolation contexts, the isolation mechanism or underlying OS is replaced when it is no longer vendor-supported, which supports keeping foundational platforms current. The overlap is limited to operating system lifecycle management; ISM-1848 is narrower to isolation mechanisms and focuses on support status rather than the latest/previous release criterion.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.