ASD ISM 1904 Apply firmware patches for non-critical vulnerabilities
What it says
Patches, updates or other vendor mitigations for vulnerabilities in firmware are applied within one month of release when vulnerabilities are assessed as non-critical by vendors and no working exploits exist.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishInstall patches for minor firmware issues within a month if there're no immediate threats.
Think of firmware as the basic software that lets your hardware work correctly. If we don't regularly update it, even for non-critical issues, those small problems can turn into bigger ones, like security holes that hackers might try to exploit later. By keeping this up to date, we're preventing minor issues from becoming major headaches down the line.
Free. Save your status, tasks and notes.
Why it matters
Delaying non-critical firmware patches beyond a month can leave known flaws unmitigated, increasing risk of compromise and device instability over time.
How to implement
System owners should keep track of firmware updates: Set up a simple schedule to check once a month for any new firmware updates or patches released by your hardware vendors.
This could involve signing up for vendor newsletters or setting a calendar reminder to visit their support website.
IT teams should install patches: Once a firmware update is identified, the IT team should download and install it on the relevant hardware.
Ensure they have a step-by-step checklist to follow, so that each device is updated correctly and tested to confirm everything works fine afterwards.
Managers should oversee update compliance: Managers need to ensure that their teams are applying firmware updates as scheduled.
They can do this by organising monthly check-in meetings to review the status of patches and updates across the organisation's devices.
Employees using devices should report issues: Staff members should be encouraged to report any abnormal device behaviour, which might indicate out-of-date firmware, to the IT team immediately.
A simple form or email template can be set up for this purpose.
Procurement should include update plans in vendor contracts: When buying new hardware, the procurement team should ensure that contracts include provisions for regular firmware updates from the vendor.
This could involve checking that the vendor has a clear support and update policy before finalising any purchase.
Keep it running
Track vendor firmware advisories; if rated non-critical and no working exploit exists, schedule and apply patches within 30 days, recording assessment and completion.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The firmware update schedule: Request to see the calendar or system that tracks when firmware updates should be checked and applied.
Look at
Entries showing regular monthly checks.
Good evidence
A well-maintained schedule with past check dates and upcoming reminders.
- Check 2 of 5What an auditor asks for
Ask for
Patch logs or records: Require logs showing when and what firmware patches have been applied.
Look at
Detailed entries indicating dates, devices, and responsible person.
Good evidence
A log file or report showing consistent monthly updates with clear details.
- Check 3 of 5What an auditor asks for
Ask for
Incident reports of firmware issues: Request any records of device malfunctions or issues reported possibly due to outdated firmware.
Look at
How quickly these were resolved and if they led to updated firmware.
Good evidence
Incident logs showing rapid resolution and follow-up action.
- Check 4 of 5What an auditor asks for
Ask for
To see vendor communication logs: Request emails or notes from vendor interactions about firmware updates.
Look at
Recent communications confirming patch releases.
Good evidence
Regular communications with vendors showing awareness and action on keeping firmware patched.
- Check 5 of 5What an auditor asks for
Ask for
To see procurement contracts: Request contracts or agreements with hardware vendors. Check for clauses about firmware support and update commitments.
Good evidence
Contracts including clauses that obligate vendors to offer regular firmware updates.
Mappings
Closest match in ASD Essential Eight: E8-PO-ML3.8, Firmware vulnerabilities patched within one month if non-critical and no exploits, which asks for the same thing.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.8.
ISM-1904 requires a specific remediation action: apply vendor firmware mitigations within one month for non-critical, non-exploited vulnerabilities. Annex A 8.8 requires organisations to obtain information about technical vulnerabilities, assess exposure, and take appropriate measures, which includes (but is not limited to) patching firmware. ISM-1904 is therefore a concrete, time-bound subset implementation of the broader ISO vulnerability management requirement.
ASD Essential Eight: 5 mappings
- E8-PO-ML3.8Firmware vulnerabilities patched within one month if non-critical and no exploitsEquivalent
This control is equivalent to E8-PO-ML3.8.
E8-PO-ML3.8 requires patches, updates, or vendor mitigations for non-critical firmware vulnerabilities to be applied within one month when no working exploits exist. ISM-1904 states the same firmware patching timeframe and the same conditions (non-critical vendor assessment and no working exploits). The scope (firmware), trigger conditions, and required timeframe align closely such that implementing one would largely satisfy the other.
This control partially overlaps E8-PO-ML3.2.
E8-PO-ML3.2 requires organisations to scan firmware at least fortnightly to identify missing patches or updates. ISM-1904 overlaps in the same firmware vulnerability domain but focuses on applying non-critical firmware patches within one month under specific conditions, not on scanning frequency. E8-PO-ML3.2 provides the detection mechanism that helps trigger the patching activity required by ISM-1904, but neither control fully replaces the other.
This control partially overlaps E8-PO-ML3.4.
E8-PO-ML3.4 requires applying non-critical operating system patches within one month on internal workstations, non-internet-facing servers, and non-internet-facing network devices where no working exploits exist. ISM-1904 mirrors the same timing and exploit/non-critical conditions but applies them to firmware rather than operating systems. They align on risk-based patch prioritisation and timeframe, but differ on the technology layer (OS vs firmware) and therefore are only partially overlapping.
This control partially overlaps E8-PO-ML3.6.
ISM-1904 requires vendor firmware patches/updates/mitigations to be applied within one month when vulnerabilities are non-critical and there are no working exploits. E8-PO-ML3.6 applies the same concept and timing, but for drivers rather than firmware. They align on the patching principle and SLA, but differ materially in technical scope (firmware vs drivers).
This control partially overlaps E8-PO-ML3.7.
ISM-1904 requires applying firmware patches within one month when vulnerabilities are non-critical and no working exploits exist. E8-PO-ML3.7 covers firmware patching as well, but for critical vulnerabilities or where working exploits exist, requiring action within 48 hours. They share the same technology domain (firmware patching) but apply to different severity/exploit conditions and timelines.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.