When Your Software Vendor Goes Dark: Lessons from Spyware

When your software vendor stops returning calls, you've got a problem. When they stop cooperating with law enforcement investigating serious security incidents, you've got a much bigger problem.

As TechCrunch reported, Israeli-American spyware maker Paragon has gone radio silent on Italian authorities investigating attacks targeting journalists and activists, despite earlier promises to cooperate. This isn't just another compliance story. It's a wake-up call for every engineering team relying on third-party software.

At AgileStack, we've seen enterprise clients scramble when vendors suddenly become unresponsive during security incidents. The Paragon situation is an extreme case, but it highlights a vulnerability that exists in every software stack: vendor accountability.

The Accountability Problem in Software Supply Chains

Your application probably depends on dozens of third-party services. Authentication providers, payment processors, monitoring tools, database services. Each one represents a potential point of failure, not just technically but contractually.

Consider what happens when a critical vendor:

• Stops responding to security incident requests
• Refuses to provide audit logs during compliance reviews
• Goes dark during a breach investigation
• Simply disappears (acquisition, bankruptcy, pivot)

The Paragon case is instructive because it shows how quickly vendor cooperation can evaporate when legal pressure mounts. One day they're promising full cooperation, the next they're ghosting investigators.

This pattern isn't unique to controversial spyware companies. We've seen SaaS providers suddenly become unresponsive when facing regulatory scrutiny. Database companies that clam up during security audits. API services that stop answering support tickets when compliance questions get tough.

What Enterprise Teams Get Wrong About Vendor Risk

Most vendor risk assessments focus on the wrong metrics. Teams obsess over uptime SLAs (99.9% vs 99.99%) while ignoring accountability mechanisms. They negotiate data processing agreements but skip incident response requirements.

Here's what actually matters when evaluating vendor accountability:

Incident Response Commitments

Your contracts should specify response times for different severity levels. Not just "we'll get back to you" but concrete commitments:

• Security incidents: 2-hour acknowledgment, 24-hour initial assessment
• Compliance requests: 5 business days for documentation
• Legal hold requests: Same-day acknowledgment

Paragon apparently had no such commitments to Italian authorities. Or if they did, they're brazenly ignoring them.

Audit Rights and Data Access

Every critical vendor contract needs explicit audit rights. This means:

• Right to request security logs within 48 hours
• Access to incident reports and post-mortems
• Ability to conduct on-site security reviews (for high-risk vendors)
• Guaranteed cooperation with regulatory investigations

The last point is crucial. Your vendor might cooperate with you while stonewalling regulators. That creates liability for your organization.

Escrow and Continuity Provisions

Code escrow is standard for on-premise software, but cloud services need equivalent protections:

• Data export guarantees (full export within 30 days of contract termination)
• Source code escrow for critical integrations
• Operational runbooks and configuration documentation
• Key personnel contact information (updated quarterly)

The Technical Implementation of Vendor Accountability

Accountability isn't just about contracts. It requires technical architecture that assumes vendors will eventually let you down.

Build Monitoring That Doesn't Depend on Vendors

Don't rely solely on vendor-provided monitoring and alerting. Implement external monitoring that can detect vendor issues independently:

// Monitor vendor API health independently
const vendorHealthCheck = {
  checkInterval: 60000, // 1 minute
  endpoints: [
    'https://api.vendor.com/health',
    'https://api.vendor.com/status'
  ],
  alertThresholds: {
    responseTime: 5000, // 5 seconds
    errorRate: 0.05 // 5%
  }
};

// Log all vendor interactions for audit trails
const auditLog = {
  timestamp: Date.now(),
  vendor: 'paragon-auth',
  action: 'user_authentication',
  requestId: 'req_123',
  responseCode: 200,
  responseTime: 145
};

Implement Circuit Breakers and Fallbacks

Every critical vendor integration needs a circuit breaker. When vendors go dark (literally or figuratively), your system should fail gracefully:

# Circuit breaker pattern for vendor APIs
class VendorCircuitBreaker:
    def __init__(self, failure_threshold=5, timeout=60):
        self.failure_count = 0
        self.failure_threshold = failure_threshold
        self.timeout = timeout
        self.last_failure_time = None
        self.state = 'CLOSED'  # CLOSED, OPEN, HALF_OPEN
    
    def call_vendor(self, vendor_function, fallback_function):
        if self.state == 'OPEN':
            if time.time() - self.last_failure_time > self.timeout:
                self.state = 'HALF_OPEN'
            else:
                return fallback_function()
        
        try:
            result = vendor_function()
            self.failure_count = 0
            self.state = 'CLOSED'
            return result
        except Exception as e:
            self.failure_count += 1
            self.last_failure_time = time.time()
            
            if self.failure_count >= self.failure_threshold:
                self.state = 'OPEN'
            
            return fallback_function()

Design for Data Portability

Assume you'll need to migrate away from every vendor eventually. Design your data models and APIs to make this possible:

• Use standardized data formats (JSON, CSV) instead of proprietary formats
• Maintain local copies of critical configuration data
• Build abstraction layers that isolate vendor-specific APIs
• Document all vendor integrations and dependencies

Building Vendor Scorecards That Actually Matter

Forget the typical vendor scorecards with their focus on feature checklists. Build scorecards that measure accountability:

Response Time Metrics

Track how quickly vendors respond to different types of requests:

• Security questions: Target 24 hours
• Compliance documentation: Target 5 business days
• Incident escalations: Target 2 hours
• Contract negotiations: Target 48 hours

Transparency Scores

Rate vendors on information sharing:

• Do they publish detailed incident post-mortems?
• Are security practices documented and accessible?
• Do they proactively communicate service changes?
• Are there clear escalation paths for urgent issues?

Regulatory Cooperation History

Research how vendors have handled regulatory scrutiny:

• Have they cooperated with investigations in your industry?
• Do they have a history of sudden policy changes?
• Are they transparent about law enforcement requests?
• Have they ever gone dark during regulatory pressure?

Paragon would score poorly on all these metrics based on their current behavior with Italian authorities.

What This Means for Your Software Architecture

The Paragon situation teaches us that vendor relationships are fragile. Today's cooperative partner can become tomorrow's unresponsive liability.

Reduce Single Points of Vendor Failure

• Multi-cloud deployments across different providers
• Alternative authentication providers configured and tested
• Multiple payment processors with automatic failover
• Backup monitoring and alerting systems

Build Audit Trails That Survive Vendor Relationships

• Local logging of all vendor API calls
• Regular backups of vendor-hosted data
• Documentation of vendor configuration and setup
• Contact information for vendor technical staff

Plan for Vendor Exit Scenarios

• Quarterly review of vendor criticality and alternatives
• Documented migration procedures for each critical vendor
• Regular testing of data export and migration processes
• Financial reserves for emergency vendor replacements

Takeaways

The Paragon case is extreme, but it's not unique. Vendors will disappoint you, ignore you, or simply vanish. Smart engineering teams plan for this reality:

• Accountability metrics matter more than feature lists when evaluating vendors
• Technical architecture should assume vendors will eventually fail or disappear
• Contracts need specific incident response and cooperation requirements
• Regular vendor exit planning prevents emergency scrambles
• Independent monitoring and logging provide insurance against vendor blackouts

The next time you're evaluating a critical vendor, ask yourself: what happens when they stop cooperating? If you don't have a good answer, you're not ready to depend on them.

Vendor relationships are partnerships, but partnerships require accountability from both sides. When vendors go dark, it's your users and your business that suffer the consequences. Plan accordingly.

---

Building something in this space? AgileStack helps teams ship enterprise-grade software without the consulting-firm overhead. Book a 30-minute call and tell us what you're working on.