Picture a cybersecurity team responsible for protecting a classified military installation in a remote operational theater. No internet connection. No cloud services. Classified and unclassified networks running on physically separate infrastructure. Their security information and event management system has to detect threats, correlate events, and generate alerts with zero external connectivity, for the entire deployment.
That is not a compliance checkbox. It is a physics problem.
The data cannot leave the facility because the facility has no connection to anything. And yet the mission requires full security visibility, every day, regardless of what is happening beyond the perimeter.
This scenario sounds extreme. The underlying principle is not. In 2026, organizations across oil pipelines, power grids, defense programs, aerospace manufacturing, and government research are all wrestling with the same foundational question: can your SIEM work where your data actually lives?
For a growing number of security teams, that question determines which vendors are even worth evaluating.
What Data Sovereignty in Security Operations Actually Means
Data sovereignty, in an operational security context, means your organization controls where every log record lives, how it moves, who can access it, and whether it ever leaves your infrastructure.
That definition is narrower and more practical than what you find in policy documents. In security operations, data sovereignty is an architecture question before it becomes a compliance question. The real test is whether a SIEM vendor can operate in an environment where data physically cannot leave.
Three distinct scenarios drive this requirement, each with different root causes but the same architectural need.
Geopolitical and regulatory data residency. Organizations operating under EU regulations, Gulf Cooperation Council requirements, or national data laws in dozens of countries need security log data to remain within specific geographic boundaries. In late 2025, France and Germany convened a Summit on European Digital Sovereignty, with member states reaffirming their commitment to strengthening Europe’s digital infrastructure as a matter of economic security. A SIEM hosted in US data centers is a non-starter for a Gulf state telecommunications provider, an EU financial institution, or any government agency with hard data residency mandates. Security practitioners across Germany and the broader EU consistently name data sovereignty as a top concern in 2026, and many specifically require the ability to manage data on-premises, including in fully air-gapped environments.
Operational technology and critical infrastructure. OT environments including pipelines, power grids, manufacturing plants, and water treatment facilities run on networks that are deliberately isolated from the internet. A SIEM deployed in an OT environment cannot route log data through a cloud platform without creating exactly the network path that OT isolation was designed to prevent.
Air-gapped and classified networks. Defense contractors, government agencies, and classified programs operate in environments where internet connectivity is physically absent, not just restricted. Updates arrive on drives. Support happens by phone. The SIEM must function indefinitely without any external connectivity.
The Four Environments Where SaaS SIEMs Fail
SaaS SIEM architectures have real limitations in certain environments. The product quality is often high, but the underlying architecture assumes connectivity that these environments structurally cannot provide.
1. Military and Defense Programs Requiring Air-Gapped Deployment
The constraint is consistent across the sector, even if the specific environment varies. Submarines operate for months without any network connectivity. Airborne command platforms, forward operating bases, and isolated military installations face the same core requirement. Classified programs at major defense contractors are air-gapped by design. Each runs as its own isolated instance with no external network path.
In every case, the SIEM must operate without internet connectivity. Licensing cannot depend on periodic online validation. Updates arrive on physical media and are applied manually. Support runs by phone because screen sharing is not permitted on classified networks.
Cloud SaaS SIEM fails here not because of product quality but because of architectural assumptions. A platform designed around persistent cloud connectivity cannot be adapted for environments where that connectivity is structurally prohibited and legally required to stay that way.
The relevant buyers include program IT leads at defense primes, government program managers, and military IT commands responsible for shipboard, airborne, and fixed installation networks. For all of them, on-premises self-managed deployment is the only viable starting architecture.
2. Critical Infrastructure OT Networks
OT security has become the fastest-growing driver of on-premises SIEM demand in 2026, and it is the use case that cloud-first architectures structurally cannot serve.
OT environments have historically been managed separately from IT infrastructure. The convergence of OT and IT networks, driven by remote monitoring, digital analytics, and expanding regulatory requirements, created a new security requirement: unified visibility across both environments from a single platform. The constraint is straightforward. OT networks cannot route to the internet. A sensor on a natural gas pipeline cannot have a data path to a cloud provider. A programmable logic controller on a power grid cannot accept an inbound internet connection. The monitoring platform must live inside the OT network boundary.
A pipeline operator under TSA Pipeline Security guidelines may require a fully air-gapped environment by regulation, with architecture that handles incident-driven ingest spikes without disrupting operations. A power grid operator under NERC CIP compliance may be moving some workloads toward cloud while still requiring fully on-premises capability where outbound connectivity is restricted. A large energy facility with mixed OT and IT infrastructure may need centralized log management across both environments, with NERC CIP retention requirements applying across the full data lifecycle.
The Federal Energy Regulatory Commission formally approved NERC CIP-015-1, effective September 2025, which mandates internal network security monitoring within Electronic Security Perimeters for high and medium-impact Bulk Electric System Cyber Systems. In each scenario, self-managed deployment is the only option that satisfies both security posture and regulatory requirements simultaneously.
1. Specialized Government Research Enclaves
Some government environments make cloud SIEM architecturally impossible before vendor evaluation begins. National laboratories, intelligence community research programs, weapons development facilities, and classified public-private research partnerships all share the same requirement: the SIEM must run entirely within the enclave boundary, isolated from every external network path.
The driving constraint is compartmentalization, not just classification. A program enclave cannot share detection infrastructure with an adjacent program inside the same agency. Each requires its own isolated SIEM instance with access controls that enforce program boundaries, not just organizational ones.
This affects procurement across the U.S. federal government, Five Eyes partner nations, and allied defense research establishments globally. In these environments, self-managed on-premises SIEM deployment is the only compliant architecture. It is never a preference. It is a requirement.
2. International Operations with Hard Data Residency Requirements
Data residency mandates affect organizations across nearly every major region: GCC member states (UAE, Saudi Arabia, Qatar), EU organizations under GDPR and NIS2, public sector contractors in the UK, Germany, and France, Australian critical infrastructure operators under the SOCI framework, Indian enterprises under the DPDP Act, and Southeast Asian organizations under Singapore’s and Malaysia’s PDPA frameworks. As the EU Data Act entered full application in early 2025, with enforcement materializing in 2026, organizations in regulated sectors including healthcare, banking, and education can no longer assume that storing data in a European data center owned by a U.S. corporation satisfies sovereignty requirements. The distinction matters: residency means bits are stored within a geographic border; sovereignty means those bits are subject only to the laws of that jurisdiction.
These organizations are not necessarily opposed to cloud deployment. The requirement is that data never crosses a national border, regardless of how it is hosted.
The hyperscalers offer in-country residency configurations, but three problems undermine them in practice. In several jurisdictions, no AWS, Azure, or GCP data center exists within the country’s borders, making compliant cloud SIEM impossible without a local hosting provider. Where regional options do exist, they carry premium pricing. And cloud provider infrastructure decisions, load balancing behavior, and terms of service can change without notice. An organization that cannot tolerate even a low-probability data egress event cannot accept residency assurance that depends on a vendor’s current policy remaining unchanged.
Beyond regulated industries, organizations with no legal obligation to keep data on-premises are increasingly choosing to do so. Three forces are driving this. First, vendor acquisition risk: when a vendor is acquired by a SaaS only company and on-premises support is phased out, customers face unplanned migration decisions. Second, AI data privacy exposure: security log data fed into cloud-hosted AI models may expose sensitive network topology, user behavior, and security gaps to third-party systems. Third, infrastructure economics: organizations that already own compute infrastructure increasingly ask why they should pay cloud compute costs for workloads that are high-volume, retention-heavy, and queried reactively.
For organizations with hard residency requirements, the SIEM must deploy on infrastructure they fully control, whether on-premises or on a country-specific hosting provider or national sovereign cloud platform. A global hyperscaler’s current residency policy is not a sufficient guarantee.
What “Run Anywhere” Requires of a SIEM
“Run anywhere” describes specific design decisions, not a marketing position. Those decisions determine whether a SIEM can function in the environments above.
No external dependencies in core operations. The SIEM must ingest, parse, normalize, search, alert, and correlate without calling any external service. Cloud SIEMs that rely on vendor-hosted threat intelligence feeds, cloud-based machine learning models, or external license validation create dependencies that fail in air-gapped environments. In a genuinely portable architecture, the processing engine, data nodes, search, alerting, and correlation all run on infrastructure the customer controls. Optional external features should degrade gracefully when connectivity is unavailable rather than causing core functionality to fail.
Self-managed licensing without connectivity requirements. A license requiring periodic online validation will fail in a disconnected deployment. The licensing model for these environments must operate without ongoing connectivity after installation. The cluster ID and license key are installed once. Validation runs locally.
Support for cross-domain and multi-site deployments. Classified environments often require SIEMs that span multiple networks with hardware security between them. A lightweight forwarder architecture on each network segment aggregates logs locally, caches them if connectivity to the central cluster is interrupted, and forwards via a controlled channel. The central cluster stays on the higher-security network.
Offline upgrade and patch paths. The standard upgrade process for a classified environment involves downloading the latest release on an internet-connected machine, transferring it to physical media, and applying it inside the air-gap. This is not a workaround. For vendors who designed for these environments, it is a documented, supported, and tested capability.
Graylog continues to support self-managed deployments across on-premises, customer-managed virtual machine, and private cloud environments. That support is a foundational design commitment, not a legacy accommodation.
Four Questions to Ask Before You Choose a SIEM
- Does the self-managed version have full feature parity with the cloud version, including AI capabilities, threat intelligence integrations, and advanced detection?
- Do core operations, including log ingestion, normalization, enrichment, detection rule execution, alerting, and compliance reporting, function without any external network calls?
- What is the documented, tested upgrade and patch path for air-gapped or disconnected deployments?
- Does the licensing mechanism work in a fully disconnected environment, and what happens when it cannot reach a validation server?
Keep The Data Where It Belongs
Return to that classified installation. No internet. Classified and unclassified networks on physically separate infrastructure. The perimeter is hardened by design, which means external compromise is far less likely than in a connected environment. But that same isolation makes insider threats the primary risk vector, and the consequences of a missed detection in these environments are not measured in data breach costs. They are measured in national security terms.
The monitoring requirement does not stop at threat detection. In air-gapped and OT environments, the same platform that watches for insider activity, anomalous access patterns, and policy violations also provides the operational visibility that keeps infrastructure running. Log data from disconnected systems tells you when a component is degrading before it fails, when a process behaves outside its normal parameters, and when a configuration change was made outside of change control. Security and operational monitoring are not separate functions in these environments. They run on the same data.
That requirement, combining security detection with operational visibility inside a hard perimeter, runs through pipelines, power grids, aerospace manufacturers, defense contractors, government research enclaves, and multinational organizations managing data across geopolitical boundaries.
Graylog was founded in Germany, grew on an open-source foundation, and built its earliest customer base among European enterprises, OT operators, and government bodies where data sovereignty was a hard requirement from day one. Self-managed deployment is not an accommodation at Graylog. It is the architecture.
For any team evaluating SIEM options, the question to settle first is not which vendor has the best detection rules or the deepest integration library. The question is whether the vendor’s architecture can operate where your data needs to stay.
Your security data tells the story of everything happening on your network. Who controls where that story is written, and who can read it, is a strategic decision. The SIEM you choose is the answer to that decision.
Graylog runs wherever your data needs to be: on-premises, air-gapped, private cloud, or Graylog Cloud.
Follow Graylog on LinkedIn for practical security and IT operations guidance built for the environments your team actually works in.
