How do you patch or mitigate CVE-2023-38035 (Ivanti Sentry Authentication Bypass)?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

CISA's required action for CVE-2023-38035 is to apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable. In practice, find every instance of Ivanti Sentry 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. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What “patch or mitigate” means for Ivanti Sentry

For this CVE, patching is not just a software-update exercise, it is an exposure-management decision for an internet-facing edge product. The practical goal is to confirm every Sentry instance, apply the vendor’s documented security update or mitigation, and, where mitigation cannot be applied safely, remove the service from exposure or retire it. That is the right mindset for an appliance-class vulnerability that attackers can reach before defenders have time to improvise.

The first step is inventory and exposure mapping. Treat Sentry as a perimeter-adjacent system that may sit outside normal application patch workflows, because the relevant question is whether any instance is still reachable and whether its current configuration allows the vendor mitigation to work as intended. If you cannot confidently verify the state of each deployment, you do not yet know whether the vulnerability is contained.

When the vendor provides a fix, use it. When the vendor provides a mitigation instead of a fix, apply it exactly as documented and verify that the control actually changes the reachable attack surface. For internet-facing gateways and appliances, configuration-only mitigations often fail if administrators leave alternate access paths, stale management interfaces, or unsupported versions in place.

How to handle systems that cannot be patched immediately

If patching must wait, the safest option is to reduce or remove exposure rather than leave the product live and hope for the best. That usually means taking the system out of service, restricting it to trusted networks only, or placing it behind stronger access controls until remediation is complete. For edge devices, the difference between “mitigated” and “still exploitable” is often whether the vulnerable service remains reachable from the internet.

This is where Edge Device Security Guide is a useful companion, because the same operational pattern applies to gateways, firewalls and other exposed appliances: know what is deployed, know what is externally reachable, and know whether the management plane is still exposed.

If the product remains in service, preserve enough logging to detect attempted exploitation and preserve enough access context to tell whether the system was already touched. In practice that means reviewing authentication, access and system logs around the period when the flaw was public and actively abused, then correlating those logs with any configuration changes, unusual sessions or unexpected process activity.

What to check after remediation

After the update or mitigation is in place, verify more than version strings. Check whether the exposed service was used to gain unauthorized access before remediation, because active exploitation turns a patching task into an incident-response task. Review for suspicious logins, unusual administrative actions, new local accounts, changed credentials, modified configuration, and outbound activity that does not fit normal appliance behaviour.

That kind of follow-up is consistent with Vulnerability Management Guide, which emphasizes verification and exception handling, not just rapid remediation. A fix that was deployed but never validated is only a claim, not a control.

If you find evidence of compromise, rotate any credentials, keys, certificates or tokens that the appliance could have exposed or mediated, and treat adjacent systems as potentially affected until proven otherwise. For an edge security device, the blast radius can extend beyond the appliance itself if it brokers access into internal networks or stores administrative secrets.

Risk and Threat Considerations

This vulnerability matters because authentication bypass on a perimeter product can turn a single reachable device into a foothold for lateral movement. Attackers do not need perfect exploitation conditions when the control they are bypassing sits at the boundary between the internet and internal trust zones.

Failure mechanism: If the vulnerable Sentry instance stays reachable and the mitigation is not applied correctly, an attacker can bypass intended authentication and use the appliance as an entry point before defenders notice.

Impact: The usual consequence is unauthorized access, follow-on credential theft, session abuse, or deeper compromise of systems that trust the appliance or its users.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 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	CVE remediation and exposure verification are continuous vulnerability management tasks.
Recommendation — Prioritise, remediate and verify the vulnerable appliance through a continuous vulnerability management process.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The question is about applying a vendor fix or mitigation for an actively exploited flaw.
	RA-5 — Vulnerability Monitoring and Scanning	Finding every Sentry instance and checking exposure requires systematic vulnerability discovery.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-fix log review is needed to detect prior exploitation and abnormal activity.
Recommendation — Apply flaw remediation promptly and validate that the vulnerable condition is removed. Continuously scan and inventory assets so exposed instances of the vulnerable product are identified. Review appliance logs for indicators of compromise and escalate any suspicious authentication activity.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	Applying vendor mitigation and tracking exposed appliances is technical vulnerability management.
	A.8.15 — Logging	The answer depends on reviewing logs after remediation for signs of earlier exploitation.
Recommendation — Track, remediate and verify technical vulnerabilities on exposed appliances. Retain and review logs so exploitation attempts and suspicious appliance activity can be investigated.

Practitioner Guidance

What to prioritise: Inventory every Ivanti Sentry instance first, then sort them by internet exposure and business criticality. Publicly reachable systems should be remediated before internal-only deployments because they carry the highest exploitation likelihood.

What to verify: Confirm that the vendor update or mitigation is actually in force on each node, and verify that no alternate path still exposes the vulnerable service. Do not rely on change tickets or patch reports alone when the asset is an internet-facing appliance.

Decision rule: If you cannot apply the documented mitigation cleanly, remove the product from service or isolate it hard enough that the vulnerable path is no longer reachable. Partial confidence is not enough when the attack path is already known and exploited in the wild.

Practitioner takeaway: For exploited edge vulnerabilities, the real control is not “patched someday”, it is “confirmed unreachable, confirmed remediated, and confirmed not already abused.”

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.

NHIMG Editorial Note
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