Manufacturing Execution Systems (MES) have become mission-critical infrastructure for modern factories. They’re the digital nervous system that keeps production lines running, optimizing resources, and meeting compliance requirements.

The latest AWS and Azure outages rehashed a common question that I often get during calls with customers and prospects. Can we deploy the MES in a multi-cloud or cloud plus on-premises configuration in a fully redundant way? As organizations explore cloud flexibility and multi-region deployments to achieve resilience, they’re discovering that distributed architectures introduce a problem far more complex than infrastructure orchestration: how do you keep your database synchronized across multiple infrastructures without destroying application performance?

Part 1: Why Your MES Cannot Afford Downtime

The Business Reality of Manufacturing Downtime

Manufacturing downtime is catastrophically expensive. According to recent industry data, unplanned downtime costs the world’s 500 biggest companies 11% of their revenues - approximately $1.4 trillion annually. In the automotive sector alone, a single hour of production stoppage now costs approximately $2.3 million - or $600 per second.

For a typical large manufacturing facility, unplanned downtime averages 323 production hours per year, translating to $532,000 per hour in lost revenue, financial penalties, idle staff time, and line restart costs - amounting to $172 million annually per plant. These aren’t edge cases or theoretical numbers - they’re institutional realities across Fortune 500 manufacturers.

Why High-Availability Isn’t Optional

A Manufacturing Execution System drives real-time production decisions: material allocation, quality checks, equipment scheduling, and regulatory compliance documentation. When your MES goes offline, you don’t just lose visibility - you lose the ability to make decisions at all. Production doesn’t pause elegantly; it halts chaotically. Work-in-progress (WIP) inventory stalls. Quality escapes increase. Regulatory traceability breaks.

This is why high-availability (HA) and disaster recovery (DR) aren’t luxuries. They’re infrastructure requirements. Organizations deploy SQL Server Availability Groups specifically to ensure Recovery Time Objectives (RTO) measured in minutes and Recovery Point Objectives (RPO) that limit data loss to acceptable windows.

The standard production deployment for a Critical Manufacturing MES includes:

• A multi-node Kubernetes cluster for application redundancy
• SQL Server Always-On Availability Groups with synchronous commits for zero-loss failover
• Network infrastructure optimized for sub-100 millisecond latency between nodes

This architecture works exceptionally well within a single region or data center. The problem emerges the moment you try to stretch it across geographies.

The technologies mentioned through out the article are illustrative. The failure scenarios we will cover apply to any sort of system that stores state.

Part 2: The Technical Nightmare of Distributed State

The Fundamental Constraint: Latency and Consistency

Here’s where the physics of networks collides with the mathematics of distributed databases. To maintain zero Recovery Point Objective (RPO) across multiple clouds or a cloud-plus-on-premises hybrid deployment, you need synchronous replication. Each database transaction must be confirmed as received and written to disk on every replica before the primary node acknowledges the write to the application.

This guarantee is powerful: if the primary datacenter burns down at 3 PM, you can fail over to your secondary in another cloud and know with absolute certainty that all committed data is present. No data loss. None.

But here’s the cost: synchronous replication is fundamentally latency-constrained.

SQL Server Always-On: The Synchronous-Commit Trap

SQL Server Always-On Availability Groups offers two fundamental modes of synchronization:

Synchronous Commit Mode:

• Every transaction is written to the primary and ALL secondary replicas’ transaction logs before the primary acknowledges success to the application
• The primary waits for all secondaries to confirm receipt and hardening
• Provides RPO = 0 - zero data loss
• Performance impact is direct and unavoidable: the application’s transaction latency increases by the round-trip time (RTT) to the farthest replica

In a single data center with fiber-optic connectivity (sub-millisecond latency), this overhead is acceptable. In a multi-cloud or hybrid cloud-plus-on-premises scenario, the numbers get brutal.

Under synchronous replication, every single database write operation adds latency to your transaction time. A manufacturing system processing production orders, recipe changes, and quality measurements might generate 100-5000 database transactions per minute across the factory floor. Each added millisecond of latency compounds.

This is why your MES becomes sluggish. User operations that should complete in single-digit seconds now require 10-15 seconds. The system feels broken - because it is.

Asynchronous Commit Mode:

• Transactions are immediately acknowledged to the application after writing to the primary only
• The primary then ships transaction logs to secondaries asynchronously, without waiting
• The secondary applies changes to its copy independently, in the background
• Performance impact: zero. You pay no latency penalty
• Data loss exposure: significant

Here’s the trap: in asynchronous mode, if your primary data center fails and your secondary is still processing transactions, you’ve lost committed transactions. The user confirmed the order. It’s gone.

Worse: in production systems, the lag can be seconds or minutes, not milliseconds. Network congestion, disk write bottlenecks on the secondary, or high transaction volume cause replication queues to back up. You have no guarantee that the secondary has ANY recent data, let alone all the data you need.

Real-World Evidence: The Azure DevOps September 2018 Outage

Don’t take my word for it. Microsoft learned this lesson the hard way.

On September 4, 2018, Azure DevOps (formerly VSTS) suffered a 21+ hour regional outage affecting South Central US, cascading to global services. A lightning strike hit the datacenter, forcing power-down procedures. When the infrastructure recovered, Microsoft faced a critical decision: fail over to the paired US North Central region using asynchronous replication, or wait for recovery.

Here’s what Microsoft’s postmortem revealed about why they couldn’t simply fail over:

“The round-trip latency is added to every write. This adds approximately 70ms for each round trip between South Central US and US North Central. For some of our key services, that’s too long… Since every write only succeeds when two different sets of services in two different regions can successfully commit the data and respond, there is twice the opportunity for slowdowns and failures. As a result, either availability suffers (halted while waiting for the secondary write to commit) or the system must fall back to asynchronous replication.”

Microsoft’s architects faced the exact tradeoff we’re describing: synchronous replication across regions destroyed performance; asynchronous replication meant unacceptable data loss risk. They chose to wait for recovery rather than fail over to a secondary they couldn’t trust.

Their conclusion is damning: “Achieving perfect synchronous replication across regions to guarantee zero data loss on every fail over across regions at any point in time is not possible for every service that also needs to be fast.”

This is a $200+ billion company with unlimited engineering resources and deep cloud platform expertise. And they still couldn’t solve this problem. That should tell you something about the fundamental constraints you’re facing.

The Real Problem: You Can’t Split the Difference

Here’s what many architects try: use asynchronous replication for cross-region links (latency), but synchronous for intra-region replicas (local data protection).

This works technically. It doesn’t work philosophically.

The moment your disaster recovery scenario is “secondary data center has everything up to 5 minutes ago,” you’re managing a distributed system in a state of eventual consistency. You’re no longer designing for zero-loss failover; you’re designing for “acceptable loss.”

For a pharmaceutical or medical devices manufacturer required to maintain traceable records of every production step, or an automotive supplier operating under strict regulatory requirements, “acceptable loss” isn’t a simple business decision - it’s a compliance question. What transactions are you comfortable losing? Which regulatory violations are you willing to explain?

And that assumes everything works as designed. In practice:

• SQL Server can switch replicas from synchronous to asynchronous automatically if the secondary falls too far behind during high load. Your “RPO = 0” guarantee silently becomes “RPO = unknown” and you won’t know until you try to failover.
• Network partitions introduce split-brain scenarios. If the WAN link flickers between your cloud provider and your on-premises facility, which replica is primary? Who’s authoritative? How do you merge divergent datasets afterward?

Additional Operational Nightmares

The latency problem is just the technical surface. Beneath it lurk operational complexities:

• Cost Explosion:

  Multi-cloud deployments require dedicated network connectivity to achieve reliable, low-latency synchronous replication. These connections run hundreds to thousands of dollars per month depending on bandwidth and geography. Your cloud bills don’t shrink; they multiply by the number of regions.

• Maintenance Complexity:

  Each cloud provider (AWS, Azure, Google Cloud) has different networking models, different security postures, different operational runbooks. A network engineer needs specialized knowledge for each. A single misconfiguration cascades across your entire deployment. Automated failover becomes a minefield of edge cases - what happens when one cloud provider has a regional outage but your on-premises facility is fine?

• Monitoring and Observability:

  In single-region, you measure lag using SQL Server DMVs and dashboard counters. In multi-region, you’re blind until you implement specialized cross-region replication monitoring, which itself becomes complex.

The Uncomfortable Reality

Multi-cloud MES deployments are achievable. They’re not easy.

The most pragmatic architectures accept the latency reality:

1. Keep synchronous replication within a single metropolitan region (cloud availability zones or co-located data centers with sub-15ms latency). This preserves RPO = 0 for local failures.

2. Use asynchronous replication for cross-region or cloud-to-premises links, accepting a defined recovery point objective (typically 1-5 minutes of acceptable data loss) and a longer recovery time objective.

3. Design your MES architecture to tolerate this limitation: Some functions (real-time production control, quality checks) stay in the primary region. Only non-critical analytics or reporting workloads run in secondary regions.

4. Invest heavily in network engineering: Private WAN links, traffic prioritization, and redundant connectivity paths are non-negotiable costs.

5. Establish clear policies about failover decisions: When do you accept data loss? Who decides? What’s your communication plan to customers? Microsoft learned that you need to give customers the choice of whether to fail over with possible data loss or wait for recovery - not decide for them.

This isn’t the “cloud is everything, everywhere” narrative that marketing decks promote. It’s the reality of maintaining both performance and reliability across distributed systems.

The hard truth: distributed systems are hard because the physics is hard. Synchronous replication provides the guarantees you want but destroys the performance you need. Asynchronous replication preserves performance but breaks your guarantees. There is no free lunch, and anyone telling you otherwise isn’t thinking through the failure scenarios.

For Critical Manufacturing’s MES customers, the question isn’t “should we do multi-cloud?” It’s “which specific failure scenarios justify which specific tradeoffs?” And that answer is different for every customer, every geography, and every regulatory environment.

Author

Hi! My name is José Pedro Silva. ✌️

I’m the R&D Director at Critical Manufacturing. Passionate about cybersecurity and everything Software Engineering.

You can find me on LinkedIn.

The manufacturing industry is undergoing a digital transformation, with Manufacturing Execution Systems (MES) becoming the backbone of modern smart factories. However, as we advance toward Industry 4.0, a new threat looms on the horizon: quantum computing. The cryptographic algorithms that currently protect our most sensitive manufacturing data may soon become obsolete. This isn’t a distant concern - it’s a present reality that requires immediate attention.

Why MES Systems Are Critical Targets

Manufacturing Execution Systems sit at the heart of every modern production facility, making them treasure troves of invaluable industrial property and operational intelligence. The data contained within these systems represents the crown jewels of manufacturing organizations.

MES systems document and store comprehensive production processes that reflect decades of research, development, and optimization. These systems contain detailed product recipes that define the exact specifications, ingredients, formulations, and processing parameters required to manufacture products. For pharmaceutical companies, these might include drug formulations; for semiconductor manufacturers, they contain precise etching and deposition processes; for food and beverage companies, they hold proprietary recipes and processing conditions.

The intellectual property stored in MES systems extends beyond simple recipes. These systems maintain complete process workflows that detail every step of production, from raw material handling to final packaging. This includes optimal processing temperatures, timing sequences, equipment settings, and quality control checkpoints that have been refined over years of production experience.

Real-Time Operational Data

Beyond static information, MES systems continuously collect and store real-time operational data that provides unprecedented visibility into manufacturing operations. This includes:

• Equipment performance data: Machine utilization rates, cycle times, throughput measurements, and overall equipment effectiveness (OEE) metrics
• Quality measurements: In-process quality checks, statistical process control data, defect rates, and product specifications
• Material traceability: Complete genealogy of materials and components, including supplier information, batch numbers, and processing history
• Resource allocation: Labor assignments, skill requirements, and productivity metrics

Production Intelligence and Optimization Data

Modern MES systems leverage advanced analytics and machine learning to optimize production processes. They store predictive maintenance algorithms, demand forecasting models, and process optimization parameters that give manufacturers competitive advantages. This operational intelligence enables manufacturers to reduce waste, improve yield rates, minimize downtime, and respond quickly to market demands.

These systems also maintains detailed audit trails and compliance data essential for regulated industries. For medical device manufacturers, aerospace companies, and pharmaceutical producers, this includes validation records, batch records, and documentation required for regulatory submissions.

Network and System Integration Data

As the central hub connecting shop floor equipment with enterprise systems, MES platforms contain integration configurations and network topologies. This includes access to external system credentials, communication protocols, system interfaces, network architectures, and security configurations that could be exploited if compromised.

The value of this collective data cannot be overstated. A compromised MES system could expose proprietary manufacturing processes to competitors, disrupt production operations, compromise product quality, and violate regulatory compliance requirements. This makes MES systems prime targets for industrial espionage and cyber attacks.

The Quantum Computing Threat Timeline

Quantum computing represents a fundamental shift in computational capability that threatens the cryptographic foundations of our digital infrastructure. Unlike classical computers that process information in binary bits, quantum computers leverage quantum mechanical properties like superposition and entanglement to achieve exponential speedups for specific types of problems.

Current State and Projections

The quantum threat to encryption is not a theoretical concern - it’s an approaching reality with increasingly precise timelines. Recent research and expert assessments paint a concerning picture:

• Conservative Estimates: The Chinese Academy of Sciences projects that quantum computers capable of breaking RSA-2048 encryption may emerge between 2045-2050. The MITRE analysis suggests RSA-2048 could remain secure until 2055-2060 under current technological constraints.

• Moderate Projections: Most cybersecurity experts predict quantum computers will break RSA-2048 within 15 years, with some estimates pointing to 2030 as a critical milestone. Gartner predicts RSA and ECC will become unsafe by 2029 and potentially broken by 2034.

• Aggressive Timelines: Some researchers warn of breakthrough capabilities emerging as early as 2028. A recent global survey found that 61% of security professionals believe quantum attacks will neutralize current encryption within 2-5 years.

The uncertainty in these timelines reflects the complexity of quantum computing development, but the overall trend is clear: the quantum threat is accelerating.

Algorithmic Breakthroughs

Recent developments have dramatically reduced the quantum computing resources required to break encryption. A 2025 study from Google Quantum AI researcher Craig Gidney suggests that breaking RSA-2048 encryption could be achieved in less than a week using fewer than one million noisy qubits - an order-of-magnitude reduction from previous estimates of 20 million qubits.

This reduction comes from algorithmic improvements and more efficient system designs, including approximate arithmetic and compressed error-correction layouts. Such breakthroughs demonstrate that progress in quantum computing can come not just from hardware advances, but also from software and algorithmic innovations.

The “Harvest Now, Decrypt Later” Attack

One of the most insidious aspects of the quantum threat is the “harvest now, decrypt later” attack strategy. Adversaries are currently collecting encrypted data with the intention of storing it until quantum computers become available to decrypt it.

Current Data Collection

Cybercriminals and nation-state actors are actively harvesting encrypted communications, stored databases, and backup systems containing sensitive manufacturing data. This includes:

• Encrypted MES database backups
• Secure communications between manufacturing sites
• Proprietary technical documentation
• Financial and competitive intelligence
• Customer and supplier information

Future Decryption Capabilities

Once cryptographically relevant quantum computers (CRQCs) become available, this stored data will become vulnerable to retrospective decryption. For manufacturing companies, this means that trade secrets, product formulations, and competitive intelligence collected today could be exposed in the future.

The timeline for this threat is particularly concerning for data with long-term value. Manufacturing processes, product recipes, and technological innovations often remain valuable for decades. A pharmaceutical company’s drug formulation collected today could still be commercially sensitive 20-30 years from now, well within the projected timeline for quantum computing threats.

This “store now, decrypt later” strategy creates an immediate urgency for implementing post-quantum cryptography, even before quantum computers become practically available. Organizations cannot wait until quantum computers are deployed to begin protecting their data - they must act now to prevent future exposure.

Interactive Quantum Timeline Simulation

To better understand when current encryption methods might become vulnerable, several organizations have developed online simulators and calculators that visualize the quantum threat timeline.

• IBM Quantum Experience provides access to both quantum simulators and real quantum processors, allowing users to experiment with quantum algorithms and understand their implications for cryptography. The platform includes educational resources about Shor’s algorithm and its impact on RSA encryption.

• Quantum Computing Timeline Calculators are available from various cybersecurity organizations that allow users to input different scenarios (qubit counts, error rates, algorithmic improvements) to estimate when specific encryption methods might become vulnerable.

• NIST Post-Quantum Cryptography Resources provide detailed timelines and migration guidance for transitioning to quantum-resistant algorithms. These resources include risk assessment tools and implementation roadmaps.

While there is no single definitive simulation website, these resources collectively offer interactive ways to explore the quantum timeline and understand the urgency of transitioning to post-quantum cryptography. Organizations should regularly consult these resources to stay updated on quantum computing progress and adjust their security strategies accordingly.

Critical Manufacturing’s Quantum-Safe Leadership

As the quantum threat becomes more tangible, manufacturing software providers must take proactive steps to protect their customers’ valuable data. That’s why Critical Manufacturing is at the forefront of this effort in the upcoming 11.2 release.

Version 11.2 is the first release to support Post-Quantum Cryptography, allowing customers to use X25519MLKEM768, a hybrid key exchange algorithm used in TLS 1.3 that combines the established X25519 elliptic curve with the NIST-standardized ML-KEM-768 post-quantum algorithm.

Support for TLS 1.3 with X25519MLKEM768 highlights Critical Manufacturing’s commitment to spearhead manufacturing excellence and MES innovation. Critical Manufacturing’s continuous dedication to security and secure architecture patterns, allows Critical Manufacturing MES to be one of the first MES solutions to provide Post-Quantum safe communication options.

The Imperative for Action

The convergence of quantum computing advancement and the critical nature of MES data creates an urgent imperative for the manufacturing industry. Organizations cannot afford to wait until quantum computers become mainstream to begin their post-quantum transition.

Immediate Steps

Assessment and Inventory: Manufacturers must immediately assess their current cryptographic implementations, identify vulnerable systems, and prioritize critical assets for protection.

Vendor Engagement: Work with MES providers, equipment manufacturers, and system integrators to understand their post-quantum roadmaps and timelines.

Pilot Projects: Begin testing post-quantum cryptographic implementations in non-production environments to understand performance implications and integration challenges.

Staff Training: Educate IT and OT teams about quantum threats and post-quantum cryptography to build internal expertise.

Long-term Strategy

The transition to post-quantum cryptography will be complex and lengthy, requiring careful planning and execution. Organizations should develop comprehensive strategies that address not just MES systems but entire manufacturing technology stacks including PLCs, SCADA systems, and enterprise applications. When well designed, a hybrid deployment approach with the right MES can significantly mitigate the risks of maintaining some legacy systems running on the shop-floor.

The quantum threat to manufacturing is real, imminent, and potentially devastating. However, with proper preparation and proactive adoption of post-quantum cryptographic solutions like those offered in Critical Manufacturing MES 11.2, the industry can maintain the security and integrity of its most valuable digital assets.

The question is not whether quantum computers will break current encryption - it’s whether your organization will be ready when they do.

This blog post is based on current research and industry developments as of September 2025. Quantum computing and post-quantum cryptography are rapidly evolving fields, and organizations should regularly update their threat assessments and security strategies.

Author

Hi! My name is José Pedro Silva. ✌️

I’m the R&D Director at Critical Manufacturing. Passionate about cybersecurity and everything Software Engineering.

You can find me on LinkedIn.