Why Disabling a Feature to Dodge a Zero-Day Is a Business Decision

When Fortinet disclosed the actively exploitedActively Exploited🛡️A vulnerability that attackers are currently using in real-world attacks, requiring immediate patching regardless of severity score. FortiMail flaw CVE-2026-104286, the fixed firmwareFirmware🏠Permanent software programmed into a device's hardware that controls its basic functions. was still "upcoming." The only thing administrators could do immediately was apply the workaround, and the primary workaround was to disable the Identity-Based EncryptionEncryption🛡️The process of converting data into a coded format that can only be read with the correct decryption key. service. That sounds like a one-line config change. It is not. IBE is the feature that lets external recipients receive encrypted mail, and many organizations turned it on specifically to satisfy a compliance requirement. Disabling it to dodge a zero-dayZero-Day🛡️A security vulnerability that is exploited or publicly disclosed before the software vendor can release a patch, giving developers 'zero days' to fix it. trades one risk for another, and deciding to make that trade is a business decision that should not be made alone at a terminal at 2 a.m.

Why a workaround that removes a feature is different

Most mitigations are additive: add a firewallFirewall🌐Security system that monitors and controls network traffic based on predetermined rules. rule, tighten a permission, enable extra logging. They reduce attack surfaceAttack Surface🛡️The sum of all points where an unauthorized user could attempt to enter or extract data from a system: exposed services, interfaces, accounts, and integrations. Reducing attack surface means removing reachability, not just patching. without taking anything away from users. A workaround that disables a feature is subtractive, and subtraction has a blast radiusBlast Radius🛡️The full set of systems, data, and access an attacker can reach after compromising a given asset. Ranking assets by blast radius rather than by how exposed they are pushes high-reach systems like a firewall management console to the top of the priority list.. Turn off IBE and external recipients can no longer retrieve the encrypted messages your organization sends them. Depending on how you use it, that can mean a healthcare provider cannot deliver results to patients, or a firm cannot send protected documents to clients, or a regulated communication simply stops flowing until the feature returns.

The security team usually has the authority to apply the workaround and the urgency to do it now. It rarely has full visibility into who depends on the feature or what obligation it satisfies. That mismatch is the trap: the fastest safe action from a security standpoint can be a significant operational or compliance event for the business. Recognizing that a subtractive workaround is a cross-functional decision, not a purely technical one, is the first step.

Frame the decision as a trade, not a toggle

The useful mental model is a balance with a clock running. On one side is the risk of leaving the feature enabled: in the FortiMail case, an unauthenticated, actively exploited path to arbitrary file writeArbitrary File Write🛡️A vulnerability class in which an attacker controls both the contents and the destination path of a file written by a target system. On a general-purpose OS it is usually equivalent to code execution, because files written to certain locations are loaded or run automatically. and, through the bridges described in How an Arbitrary File Write Becomes Code Execution Through ld.so.preloadld.so.preload🛡️A Linux file read by the dynamic linker that lists shared libraries to load into every dynamically linked process before any other library. Designed for legitimate interposition, it is a favored persistence mechanism: writing a path into it forces attacker code to load into processes system-wide, including root-owned ones., full compromise of a mail gateway. On the other side is the cost of disabling it: broken encrypted delivery and a possible compliance gap. The clock is the exploitation window, which for a no-patch zero-day is now.

Framed that way, the answer is usually to disable, because the downside of compromise dominates. But the framing is what lets you say so defensibly, communicate it to the people affected, and plan the return. It also surfaces the cases where the answer is different, for example an appliance that was never internet-exposed, where restricting the management interface may close the risk without removing the feature at all.

Decide the hard calls before the advisory lands

The reason this decision goes badly is almost always that it is being made for the first time under pressure. The fix is to pre-decide. For each security feature your organization depends on, know in advance:

• **Who owns it.** Which business function relies on this feature, and who can authorize taking it offline temporarily.
• **What breaks without it.** The concrete user-visible and compliance consequences of disabling it, written down before you need them.
• **How to communicate the outage.** A ready path to notify affected users and, where relevant, to document the compliance gap and its compensating controls.
• **What the return trigger is.** The specific condition, usually "fixed build installed and verified," that tells you to re-enable, and who confirms it.

This is the same discipline that makes a no-workaround advisory survivable, where the only options are patch now or disconnect. Pre-deciding turns a panicked debate into executing a plan.

Track the mitigation as debt, not a fix

A subtractive workaround leaves you in a degraded state, and degraded states have a way of becoming permanent because nothing is obviously broken. The mail still flows for internal users; only the encrypted external path is gone, and that absence is quiet. Record the disabled feature as explicit, dated remediation debt with an owner and a due condition. When the fixed FortiMail build ships, someone has to install it, verify it, and re-enable IBE, and the system that reminds them should not be one person's memory. Detecting whether anything changed on the appliance while you were exposed is a parallel task, covered in How to Detect Unauthorized File Changes on a Hardened Appliance.

The planning payoff

The FortiMail event is a clean example of a pattern that recurs with every feature-rich security appliance: the capability you added for compliance becomes the attack surface, and the emergency mitigation is to remove the capability. Organizations that had already mapped who owns which feature and what breaks without it applied the workaround within the hour and communicated it cleanly. Organizations that had not spent that hour arguing about whether they were allowed to, while the exploitation window stayed open. The config change is one line. The decision behind it is the work, and it is work best done before the advisory arrives.