CISA’s required action for CVE-2020-24363 is to apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable. In practice, find every instance of TP-Link TL-WA855RE in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service.
What “patch or mitigate” means for this KEV entry
CVE-2020-24363 is not just a “check for updates” item. The practical task is to confirm whether any TP-Link TL-WA855RE units are still reachable, then apply the vendor’s documented security update or mitigation path. If you cannot apply the fix, the safe outcome is to remove internet exposure or retire the device rather than leaving a known exploitable management path in place.
Because this vulnerability is in a network device, the first question is whether the device is actually in your asset inventory and whether it is exposed beyond a trusted management network. A device that is hard to see is often the one that stays vulnerable longest, so inventory, reachability testing, and owner assignment matter as much as the remediation itself.
If you need a broader operating model for that work, the Vulnerability Management Guide is the right internal reference point for prioritisation, verification, exceptions, and closure criteria.
How to reduce exposure if the fix cannot be applied immediately
When patching is delayed, the safest mitigation is to shrink the attack surface around the device. That usually means limiting management access to a trusted network, removing direct internet exposure, and ensuring the device is not reachable from segments where it does not need to operate. For consumer and small-office networking gear, exposure is often the real problem, not just software versioning.
For this class of device, the mitigation should be treated as temporary risk reduction, not a permanent control. If the device still has to remain in service, review whether it is performing a function that can be replaced by a supported product with stronger administrative controls and clearer lifecycle support. If not, decommissioning is often the cleaner risk decision.
For device hardening and broader IoT exposure control, IoT Security Guide is the closest internal fit because it covers firmware updates, segmentation, device identity, and attack-surface reduction.
What to verify after remediation
Do not stop at “the update was applied.” Verify that the vulnerable unit has been identified correctly, that the vendor instruction was followed exactly, and that the management interface is no longer exposed in the way the vulnerability requires. If the product cannot be patched, verify that the compensating control is real, not just documented.
After the change, check for signs that the device was already touched before remediation. On consumer and edge devices, earlier compromise can be subtle, so the practical check is whether configuration, DNS, forwarding rules, credentials, or remote-management settings changed unexpectedly before the fix was applied.
Where exposure or prior compromise is a concern, the NIST and CISA reference points are the most useful public sources: CISA Known Exploited Vulnerabilities Catalog, NIST National Vulnerability Database, and CVE Program.
Risk and Threat Considerations
The main risk is remote misuse of a device that is expected to sit quietly on the network. If the product remains exposed, an attacker can use a management or critical-function weakness to change device behaviour, gain foothold in the local environment, or use the device as a pivot point into other assets.
Failure mechanism: The weakness becomes dangerous when an internet-facing or broadly reachable device accepts actions that should have required stronger authentication or tighter network restriction, allowing unauthorised control without normal administrative friction.
Impact: The result can be device takeover, configuration tampering, loss of network trust, and downstream exposure of the systems that depend on the device for connectivity or segmentation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The issue requires identifying, prioritising, and remediating a known exploited vulnerability. |
| Recommendation — Track exposed devices, prioritise remediation, and verify closure for the KEV-listed flaw. | ||
| NIST CSF 2.0 | PR.AA-05 — Protective Technology | Mitigation depends on restricting exposure and reducing reachable attack surface on the device. |
| Recommendation — Restrict network reachability and administrative paths to the device. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | The question is about handling a known vulnerability through patching or compensating mitigation. |
| Recommendation — Apply vulnerability remediation and record any compensating controls or exceptions. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | This KEV entry calls for finding affected assets and confirming remediation status. |
| CM-7 — Least Functionality | Disabling unnecessary exposure is a core mitigation when patching is unavailable. | |
| Recommendation — Scan for the device, confirm exposure, and validate remediation or exception handling. Remove unnecessary management exposure and disable any unneeded access paths. | ||
Practitioner Guidance
What to prioritise: Identify every deployed TL-WA855RE instance before you spend time on patch mechanics. In practice, the longest-lived exposure is usually hidden inventory, not difficult remediation.
Decision rule: If the vendor fix can be applied, do that first and then confirm the management plane is no longer exposed where it does not need to be. If it cannot be applied, treat removal of internet exposure or retirement of the device as the default safe path, not an exceptional one.
What to verify: Keep evidence of the device model, the firmware or mitigation state, the network location, and the exact compensating control used. That is what lets you prove the vulnerability is handled rather than merely noted.
Practitioner takeaway: For exposed network hardware, the right question is not only “is it patched?” but “does it still have a reachable path that makes the bug exploitable?” If the answer is yes and no fix exists, eliminate reachability or remove the device.
Related resources from NHI Mgmt Group
- CVE-2020-24363 (TP-link TL-WA855RE Missing Authentication for Critical Function)
- How do you patch or mitigate CVE-2025-32433 (Erlang Erlang/OTP SSH Server Missing Authentication for Critical Function)?
- How do you patch or mitigate CVE-2023-28461 (Array Networks AG and vxAG ArrayOS Missing Authentication for Critical Function)?
- How do you patch or mitigate CVE-2023-27532 (Veeam Backup & Replication Cloud Connect Missing Authentication for Critical Function)?