How do you patch or mitigate CVE-2019-6693 (Fortinet FortiOS Use of Hard-Coded Credentials)?

CISA’s required action for CVE-2019-6693 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 Fortinet FortiOS 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 the fix actually requires for FortiOS hard-coded credentials

CVE-2019-6693 is a hard-coded credential problem, so the first decision is exposure mapping, not guessing whether the appliance is “probably patched.” Identify every FortiOS instance, confirm whether it is internet-facing, and then apply the vendor security update or documented mitigation that corresponds to that deployment model. Where you need broader context on how appliance hardening and management exposure fit together, the Edge Device Security Guide is the right internal reference point.

Because hard-coded credentials are a built-in access path, the operational question is whether the affected device can still be trusted to enforce unique authentication. If the vendor mitigation removes the exposure, verify that the management plane is no longer reachable from untrusted networks and that any default or embedded access path is gone. That same lifecycle issue is why the Secret Sprawl Challenge remains a useful companion for understanding why hardcoded credentials are so difficult to eliminate cleanly.

How to handle systems you cannot patch immediately

If patching or the vendor mitigation must wait, reduce the reachable attack surface first. Remove internet exposure, restrict management interfaces to trusted administration paths, and treat any externally reachable FortiOS deployment as an urgent exception until it is fixed or retired. For teams that manage rotating credentials across appliances and other non-human identities, NHI Rotation Challenges explains why compensating controls and dependency mapping matter when immediate rotation is not realistic.

Do not rely on obscurity, undocumented firewall rules, or the assumption that an exploit will not be used against your specific device. If the product cannot be brought to a supportable secure state, discontinuation is the safest course, because a hard-coded credential remains an authentication weakness even when the rest of the configuration looks healthy. In practice, the safest fallback is to remove the device from any role that depends on trusted remote access and replace it with a supportable alternative.

What to verify after remediation

After the fix or mitigation is applied, validate the outcome as an access-control problem, not just a software-update task. Confirm the device no longer exposes the vulnerable management path, confirm administrative access requires the intended authenticated route, and confirm there is no residual reliance on the embedded credential for normal operations. When the remediation touches secrets handling more broadly, the Secrets Management Guide helps frame the follow-on controls that prevent this kind of exposure from recurring.

Also check for signs of prior compromise before declaring the issue closed. Review management logs, authentication events, configuration changes, and any unexpected outbound connections from the appliance, then decide whether credential rotation, session invalidation, or broader rebuilding is warranted based on what the device could have exposed. If the vulnerability sat on a public-facing system, treat the investigation as part of the remediation, not as an optional after-action.

Risk and Threat Considerations

Hard-coded credentials create a direct trust-break: if an attacker can reach the service, they may be able to authenticate without knowing a unique secret. That makes the issue attractive for opportunistic exploitation, especially on internet-facing appliances where management interfaces are reachable and rarely monitored as closely as user-facing applications.

Failure mechanism: The embedded credential can be used as a standing authentication path, so the attacker does not need password guessing, phishing, or prior account access. If the device is exposed and the vendor mitigation is not in place, the weakness can become an immediate entry point into the management plane.

Impact: Successful abuse can lead to administrative control of the appliance, configuration tampering, traffic redirection, or use of the device as a pivot into the wider network. Even when no intrusion is confirmed, the presence of a hard-coded credential means the environment has a latent access path that should be treated as high-risk until removed.

Standards & Framework Alignment

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

NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Hard-coded credentials are an authenticator lifecycle problem for the device.
	AC-17 — Remote Access	The issue is most dangerous when management access is exposed remotely.
Recommendation — Remove embedded credentials and enforce managed credential rotation and revocation. Restrict remote management paths to approved and monitored access channels.
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	Appliance hardening and exposure reduction are central to mitigation.
	CIS-5 — Account Management	Embedded credentials require account and access review to ensure no standing access remains.
Recommendation — Harden the appliance and disable exposed management services that are not required. Review privileged access and remove any standing accounts or secrets tied to the appliance.
NIST CSF 2.0	PR.AA-05 — Protective Technology – Identity Management, Authentication and Access Control	The mitigation depends on restoring trustworthy authentication and access control.
Recommendation — Enforce authenticated access controls and eliminate embedded authentication shortcuts.

Practitioner Guidance

What to prioritise: Inventory every FortiOS instance first, then sort them by exposure. Publicly reachable devices need the fastest action, because internet-facing management is the condition that turns a hard-coded credential into an operational compromise path.

Decision rule: If the vendor update or documented mitigation is available, apply it and verify the management plane is no longer exposed through the vulnerable path. If remediation cannot be completed quickly, isolate the device and treat continued exposure as an exception requiring explicit owner approval and a retirement plan.

What to verify: Validate that you have removed not only the software issue but the reachable access path, then review logs for signs of earlier abuse before closing the case. A clean patch without exposure reduction is usually not enough for this class of weakness.

Practitioner takeaway: With hard-coded credentials, the real remediation target is trusted access, not just version change, because the safest outcome is a device that no longer presents an externally reachable authentication shortcut.