How do you patch or mitigate CVE-2023-35078 (Ivanti Endpoint Manager Mobile Authentication Bypass)?

CISA’s required action for CVE-2023-35078 is to apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable. In practice, find every instance of Ivanti Endpoint Manager Mobile (EPMM) 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 CVE means operationally for Ivanti EPMM

CVE-2023-35078 is not a case where teams can safely “monitor and wait.” The practical response is exposure inventory first, then the vendor fix or documented mitigation, and if neither is available, remove the product from internet reach or retire it. Because the issue is an authentication bypass, any externally reachable EPMM instance should be treated as a priority exposure until you confirm it is remediated.

The most useful first question is not whether a scanner says “vulnerable,” but whether the specific EPMM deployment is still serving traffic, reachable from untrusted networks, and in a state where the vendor-supported mitigation can actually be applied. If the answer is yes, treat it as an active remediation item, not a deferred risk acceptance.

For teams that manage multiple mobile management platforms, this is also a configuration governance problem. A product can be technically present, patched in one environment, and still exposed in another if internet-facing routing, load balancers, DNS, or stale appliances were missed during inventory. That is why the remediation decision has to be tied to the full deployment footprint, not just a software version list.

How to confirm exposure and apply the fix

Start by finding every Ivanti Endpoint Manager Mobile instance in production, test, DR, and any outsourced or shared hosting environment. Confirm whether each instance is internet-facing, whether the vendor security update or mitigation can be applied as instructed, and whether any emergency compensating control is already in place. Use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog as the source of truth for required action and current status.

When the vendor fix is available to you, the right sequence is to apply it, verify the service is still functioning as intended, and then validate that the authentication bypass condition no longer exists in the exposed path. If you are using a maintenance window, make sure the rollback plan is real, documented, and tested enough to restore service without reintroducing exposure.

If the deployment cannot be patched immediately, the mitigation is to reduce or remove reachability. That usually means isolating the service from the public internet, restricting access to trusted administration paths, and limiting who can reach the management interface while you work through the vendor guidance. A temporary control is only useful if it actually blocks the exposed path, so verify network boundaries rather than assuming the product is “effectively hidden.”

For patch prioritisation, use the exposure itself, not just the product name, to decide urgency. A vulnerable appliance that still accepts external requests is materially different from one confined to an internal management network. If your estate includes both, they should not be treated as equal remediation candidates.

What to do if patching must wait

If you cannot apply the vendor update or mitigation right away, the safer choice is to narrow the blast radius rather than hope the system remains unexploited. Remove public exposure, enforce tight administrative access, and document the exception with an expiration date. If you cannot create a credible containment boundary, discontinuing use is the lower-risk path.

When an emergency workaround is the only option, validate the control from outside the trusted network as well as from inside it. Attackers look for the path that still works, not the one the change ticket intended to close. A mitigation that exists only on paper should be treated as incomplete.

Also check whether the appliance was ever exposed long enough for credential theft, session theft, or configuration tampering to occur before the fix. For internet-facing management products, the absence of a confirmed exploit does not prove the absence of compromise. If logs are limited, assume your visibility is incomplete and raise the bar for verification.

Risk and Threat Considerations

An authentication bypass on a mobile device management platform can turn a management plane into an attacker entry point. That matters because management systems often sit close to device policy, enrollment, configuration, and administrative trust relationships, so compromise can have broader downstream consequences than a single application login.

Failure mechanism: If the product remains reachable while the bypass condition exists, an attacker may be able to obtain unauthorized access to administrative functions or manipulate the management plane without valid credentials. That can lead to device policy abuse, configuration changes, or follow-on access to connected assets.

Impact: The likely impact is not limited to one console session, it is the potential expansion of control over the mobile estate that the platform manages. In a real incident, that can create a path to broader operational disruption, data exposure, or secondary compromise of managed endpoints and associated secrets.

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 SP 800-53 Rev 5 and NIST CSF 2.0 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	KEV-listed flaws require fast identification, prioritization, and remediation.
Recommendation — Prioritize and remediate the exposed EPMM instance before lower-risk backlog items.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	This CVE response depends on finding every exposed instance and verifying remediation.
	SC-7 — Boundary Protection	Mitigation may require removing or constraining internet exposure when patching is delayed.
Recommendation — Scan for all EPMM instances and verify the vulnerable service is actually remediated. Restrict or remove external access to the EPMM management interface until fixed.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	The page concerns applying the vendor fix or mitigation for an actively exploited vulnerability.
Recommendation — Track the vendor fix, apply the mitigation, and close out the vulnerability exception promptly.
NIST CSF 2.0	PR.IR-01 — Networks, systems, and assets are managed to protect against vulnerabilities and service disruptions	The response centers on inventorying, patching, and reducing exposure of the affected system.
Recommendation — Manage the exposed EPMM asset and reduce its attack surface until remediation is complete.

Practitioner Guidance

What to verify: Confirm each EPMM instance, its exposure path, and whether the vendor mitigation was applied on the exact service that receives external traffic. Do not rely on a generic patch compliance report if it does not prove the public-facing instance was covered.

Escalation / exception: If you cannot both patch and contain the system, escalate immediately to a service-owner decision on removal or decommissioning. For a KEV-listed authentication bypass, prolonged exception handling is usually a sign that the business has already accepted avoidable exposure.

Practitioner takeaway: For a KEV-tracked authentication bypass, the correct judgment is to remove attack surface first and argue about convenience second, because an uncontained management plane is a security problem even before you know whether it has been abused.