CISA's required action for CVE-2024-55591 is to apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable. In practice, find every instance of Fortinet FortiOS and FortiProxy 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 this Fortinet CVE means operationally
CVE-2024-55591 is a patch-or-mitigate-now issue, not a tune-up. The practical question is whether any FortiOS or FortiProxy instance in your environment is still reachable in a way that leaves the authentication bypass usable. If it is, treat the product as exposed until the vendor update or documented mitigation is in place.
Start with asset confirmation, because remediation only works if you have complete coverage. Find every Fortinet FortiOS and FortiProxy deployment, including edge appliances, clustered systems, lab systems, and devices that were assumed to be internal but still have management or user access paths reachable from outside. For internet-facing appliances, the exposure check is as important as the patch itself.
When the vendor security update is available for the exact platform, apply it first and verify that the appliance is running the corrected build. When the vendor mitigation is the only option, implement it exactly as documented and then re-test access paths that could have allowed the bypass. If the product cannot be fixed or safely mitigated, the only defensible choice is to remove internet exposure or discontinue use of the product.
How to reduce exposure before and after remediation
FortiOS and FortiProxy sit in a high-consequence place in the stack, so the risk is not just unauthorized login, it is what an attacker can reach after that login path is bypassed. That is why boundary reduction matters: restrict administrative reachability, remove unnecessary external exposure, and validate that the device is not serving as a broad trust bridge into other systems.
For edge and appliance-oriented remediation, the most relevant internal reference is the Edge Device Security Guide, because it covers exposed management planes, appliance hardening, firmware integrity, logging minimums, and end-of-life planning. Those are the controls that usually determine whether a vulnerable perimeter product is merely outdated or actually exploitable.
Use the vendor advisory and the CISA KEV catalog to confirm exact product scope, required action, and whether the issue is treated as actively exploited. Do not rely on a generic patching window or a routine maintenance cycle when the vendor has already issued a special remediation path.
What to check if you cannot patch immediately
If patching must wait, the priority is to contain the reachable attack surface and look for signs that the bypass was already used. That means checking access logs, administrative events, unusual configuration changes, new accounts, altered policies, and any outbound connections that do not fit the appliance’s normal role. If the device sits in front of VPN, web proxy, or remote access services, review those pathways as well.
For this kind of bypass, the biggest mistake is assuming that “no obvious crash or outage” means no compromise. Authentication bypasses are often quiet, and the interesting evidence may be indirect, such as unexpected sessions, configuration drift, or changes to forwarding and inspection rules.
Use NIST National Vulnerability Database, CVE Program, and CISA Known Exploited Vulnerabilities Catalog to validate the record and track remediation status, then pair that with FIRST EPSS when you need a prioritisation signal for related exposure across the estate.
Risk and Threat Considerations
Authentication bypass on an internet-facing security appliance can turn a perimeter control into an access path. The risk is not limited to unauthorized login, it includes configuration tampering, policy changes, traffic interception, and the possibility that the appliance becomes a launch point for deeper access.
Failure mechanism: The attacker abuses the bypass to reach administrative or privileged functions without valid authentication, then uses the appliance’s trusted position to change policy, observe traffic, or pivot into connected environments.
Impact: The compromise can expose credentials, sessions, internal traffic, or network control, and it can create a durable foothold if the appliance is not rebuilt or fully verified after remediation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems are inventoried | Asset inventory is required to find every affected FortiOS/FortiProxy instance. |
| PR.AA-01 — Identities and credentials are managed for authorized devices, users and processes | Authentication bypass makes access control and credential governance central to containment. | |
| Recommendation — Inventory all Fortinet appliances and verify exposure paths before remediation. Restrict and review administrative access paths on exposed appliances. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The question is about applying the vendor fix or mitigation for a known flaw. |
| AC-6 — Least Privilege | Limiting appliance access reduces impact if authentication is bypassed. | |
| Recommendation — Apply the vendor remediation or documented mitigation for the vulnerable product. Limit administrative reachability and privileged access to the appliance. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Mitigation depends on hardening exposed appliances and removing unnecessary exposure. |
| Recommendation — Harden the appliance and remove unnecessary external exposure. | ||
Practitioner Guidance
What to prioritise: Patch or mitigate every exposed instance first, then verify that the device is no longer internet reachable unless that exposure is explicitly required and protected. If you have multiple Fortinet deployments, prioritise the ones that sit at the perimeter or broker access to sensitive internal services.
What to verify: Confirm the corrected vendor build or mitigation state, then validate that administrative access, remote access, and any management interface are constrained to the intended path only. If the device could have been exposed, treat post-fix verification as a separate task from installation.
Practitioner takeaway: For authentication-bypass CVEs on edge appliances, the real decision is not “patched or not,” it is whether the device still has enough trust and reach to matter if someone gets in.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2025-24472 (Fortinet FortiOS and FortiProxy Authentication Bypass)?
- Is CVE-2024-55591 (Fortinet FortiOS and FortiProxy Authentication Bypass) being exploited in the wild?
- CVE-2024-55591 (Fortinet FortiOS and FortiProxy Authentication Bypass)
- How do you patch or mitigate CVE-2024-0012 (Palo Alto Networks PAN-OS Management Interface Authentication Bypass)?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org