When a zero-day vulnerability hits your vendor's platform, you're often told to wait for the patch and trust the process. But this advice hides a tougher reality: vendors make disclosure decisions based on their own risk assessments, not yours.
Two recent incidents illustrate this issue. Kiteworks advised customers to power down its data-protection platform during a nine-hour window while addressing a vulnerability. Citrix remained silent on reported attacks until releasing a patch. Both approaches have defenders, but neither prioritizes your operational continuity.
The myths about zero-day disclosure persist because they let everyone avoid uncomfortable accountability questions. Here's what the standard playbook gets wrong.
Myth 1: Vendors Who Stay Silent Are Protecting You
The Reality: Silence protects the vendor's timeline, not your assets.
When Citrix stayed silent on reported attacks before releasing a patch, the company controlled the narrative. No customer panic, no premature shutdown decisions, no reputational damage until the fix was ready. That's vendor risk management, not customer protection.
You can't defend against a threat you don't know exists. If active exploitation is underway and your vendor hasn't told you, you're making decisions based on incomplete information. The vendor manages their patch development cycle without pressure, while you're left handling an incident you didn't know about.
The calculation changes when you're explaining to your board why customer data was exfiltrated through a vulnerability the vendor knew about but didn't disclose. NIST SP 800-61 requires you to detect, analyze, contain, and eradicate incidents. You can't do any of that if your vendor decides you don't need to know yet.
Myth 2: Immediate Disclosure Creates Unnecessary Panic
The Reality: Panic comes from losing control, not from having information.
Kiteworks advised a shutdown during a nine-hour window. That's disruptive, but it's also a decision point. You can evaluate whether nine hours of downtime is acceptable given your risk tolerance, backup arrangements, and contractual obligations.
What you can't evaluate is a risk you don't know about. The "don't create panic" argument assumes you're incapable of making rational decisions under pressure. If your incident response plan can't handle a vendor-driven event, you have bigger problems than vendor disclosure timing.
Informed decisions beat comfortable ignorance. Your Incident Response Plan should define how you'll handle vendor-disclosed vulnerabilities, including criteria for temporary service suspension. If it doesn't, you're not prepared for the disclosure timing debate anyway.
Myth 3: Waiting for a Patch Is the Responsible Approach
The Reality: Patch availability doesn't eliminate the window of exposure you've already experienced.
Citrix's approach delivers a patch and disclosure simultaneously. Clean, simple, no ambiguity about remediation steps. But any exploitation that occurred before the patch was available happened while you were operating normally.
Your forensic investigation just got harder. You don't know when the vulnerability became actively exploited. You don't know which logs to prioritize. You don't know whether to treat the past week or the past month as potentially compromised. The vendor's patch timeline doesn't align with your investigation timeline.
NIST SP 800-61 describes the Incident Response Lifecycle: preparation, detection and analysis, containment/eradication/recovery, and post-incident activity. Delayed disclosure compresses your detection and analysis phase into the moment you receive the patch notice. You're simultaneously learning about the vulnerability, trying to understand your exposure, and rushing to patch. That's not responsible incident management; that's crisis reaction.
Myth 4: Vendors Know Best When Disclosure Serves Security
The Reality: Vendors optimize for vendor outcomes, which sometimes align with security and sometimes don't.
Both Kiteworks and Citrix made rational decisions based on their risk models. Kiteworks prioritized customer awareness and accepted the operational disruption cost. Citrix prioritized patch readiness and accepted the non-disclosure risk. Neither decision was wrong from the vendor's perspective.
From your perspective, you need disclosure timing that aligns with your risk tolerance, operational requirements, and regulatory obligations. SEC Cybersecurity Disclosure rules require material incident disclosure within four business days. That clock starts when you determine materiality, which you can't do if you don't know the incident exists.
The Digital Operational Resilience Act mandates financial entities classify and report ICT-related incidents. NIS2 Directive requires significant incident reporting within 24 hours of awareness. Your vendor's disclosure philosophy doesn't pause your regulatory timeline.
Myth 5: Your Contract Protects You Either Way
The Reality: Standard vendor agreements don't specify disclosure timing, investigation support, or liability for delayed notification.
Review your vendor contracts. Most contain vague language about "timely notification" of security issues. What's timely? When the vendor decides it's timely. Who determines severity thresholds that trigger notification? The vendor does.
You're operating under their disclosure framework, not yours. If you need notification within specific timeframes, you need contract language that defines those timeframes. If you need access to forensic evidence, you need contract language that guarantees preservation and access. If you need the vendor to support your regulatory reporting, you need contract language that defines their cooperation obligations.
The absence of specific contract terms means the vendor chooses their disclosure approach based on what works for them. Sometimes that aligns with what works for you. Sometimes it doesn't. Hope isn't a control.
What to Do Instead
Stop debating whether vendors should disclose immediately or wait for patches. Start building contract requirements and operational processes that give you decision authority regardless of vendor philosophy.
Define disclosure SLAs in your vendor contracts. Specify that you'll be notified within a defined timeframe when the vendor becomes aware of active exploitation, regardless of patch status. Define what constitutes awareness. Define what constitutes active exploitation. Make it measurable.
Require forensic cooperation in your agreements. You need log access, timeline information, and technical details sufficient to conduct your own impact assessment. The vendor's patch doesn't answer whether your data was accessed. Build contract language that requires evidence preservation and access.
Build vendor-incident scenarios into your tabletop exercises. Practice the decision tree: vendor discloses without a patch, do you suspend the service? Vendor patches without prior disclosure, how do you investigate retroactively? Your Computer Security Incident Response Team needs reps on vendor-driven events, not just internal incidents.
Map vendor dependencies to regulatory obligations. Know which vendors support systems that trigger SEC disclosure requirements, NIS2 reporting, or Digital Operational Resilience Act obligations. When those vendors have incidents, your regulatory clock is ticking whether they've told you or not.
Establish your own detection capabilities. Don't rely solely on vendor disclosure. Monitor for anomalous behavior in vendor-provided services. Abnormal authentication patterns, unusual data access, unexpected network connections. You can't catch every zero-day, but you can catch some exploitation activity before the vendor tells you it's happening.
The Kiteworks and Citrix approaches both have merit. They also both have gaps. Your job isn't to pick the right vendor philosophy. Your job is to build contracts and processes that protect your organization regardless of which philosophy your vendor chooses.
