Graylog for manufacturing

Why Graylog for manufacturing starts with the plant network, not the SIEM

Self-hosted Graylog fits a manufacturing deployment when the plant network is the first design question and the security tooling comes second. A plant usually has an OT network of PLCs, SCADA servers and historians, an IT network of directories and business applications, and one or more remote sites on links that cannot carry raw logs at will. The IT and OT teams often run different tools and answer to different people. Before anyone builds a dashboard, the team needs to agree which logs leave each network, through which forwarder or input, and who may search them. If the answer is that logs from the control network must cross a segmentation boundary, the design has to show which ports and directions are permitted, and that decision shapes everything after it. Manufacturers in scope of NIS2 under Annex II should also confirm with counsel and their national authority how the incident reporting timelines apply to them, because Graylog stores the evidence but does not decide what counts as a significant incident.

Three conditions change the build compared with a corporate SIEM project. First, log sources are segmented: Windows event forwarding and firewall syslog from the office zone are straightforward, while engineering workstations and controllers may only be reachable through a DMZ collector, so the team should map each source to a collection point before choosing inputs. Second, remote sites with limited bandwidth need local buffering and filtering so that a link outage does not lose events, and the message journal and disk sizing at each Graylog node should be checked against the outage the plant must tolerate. Third, changes to Graylog that touch collection on the plant side must follow the safety and uptime rules set by the site, so upgrades, input restarts and pipeline changes need agreed change windows. Under the Graylog Open license, which is SSPL-1.0 and not an OSI-approved open source license, the procurement team should review the license terms with its legal counsel before committing, and should confirm which inputs and features require an Enterprise or Security license.

Which manufacturing requirements shape the Graylog build

This table maps the standards and EU rules that most often apply to manufacturers onto concrete Graylog build decisions. Read each row as a question to answer during design: what must be logged, how quickly it must be reported, and which parts of the plant the log pipeline must reach. Confirm which rows apply to your sites with your compliance lead before you size storage or alerting.

Requirement	Source	What it means for the build
ISA/IEC 62443 asset owner program and zones and conduits	ANSI/ISA-62443-2-1-2024 (security program requirements for asset owners); ISA-62443-3-3-2013 (system security requirements and security levels)	Define zones and conduits first, then place Graylog inputs and collectors so that logs from each zone cross a documented boundary and can be traced to a named owner.
OT security with performance, reliability and safety in view	NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security (September 2023)	Use passive or low-impact collection from PLCs, HMIs and controllers, and schedule any agent or query activity around production and safety limits.
NIS2 Annex II manufacturing scope	Directive (EU) 2022/2555, Annex II, NACE Rev. 2 divisions 26 to 30 and medical and in vitro diagnostic devices	Confirm whether each legal entity is in scope, since the sector list determines whether incident detection and reporting must run from Graylog data.
NIS2 reporting windows	Directive (EU) 2022/2555, Article 23(4)	Build alert paths that reach the incident team within 24 hours for an early warning, 72 hours for a notification, and one month for a final report, and keep timestamps and evidence needed for each step.
Cyber Resilience Act reporting and fines	Regulation (EU) 2024/2847, Article 14 (reporting from 11 September 2026) and Article 64 (fines of up to EUR 15 million or 2.5% of worldwide annual turnover)	Track actively exploited vulnerabilities and severe incidents in products you make, and keep logs that show when each was detected and reported.
Machinery Regulation essential requirement	Regulation (EU) 2023/1230, Annex III, 1.1.9 (applies from 14 January 2027)	Log connections to machinery from other or remote devices so that you can show that unauthorized connections are detected and do not lead to hazardous states.

Which Graylog for manufacturing inputs and modules matter on the plant floor

A plant runs OT, IT and security sources that each need different handling in Graylog. The components below decide how events arrive, where they are kept, who sees them and how someone is alerted, so each one is worth designing before the first log lands.

Syslog and GELF inputs for network gear

Firewalls, switches and routers at plant sites usually send events over syslog, and some applications can send GELF. Decide which devices use UDP and which use TCP, since UDP can drop messages under load and a dropped firewall event may never be recovered. Confirm each device's syslog format and timestamp time zone before you build parsing rules, because mismatched time zones make cross-site investigation unreliable. Inputs are available in Graylog Open.

Beats inputs for Windows hosts

Windows servers, engineering workstations and historian hosts produce security and system events that Beats-based shippers can forward to Graylog. Plan which event channels and security logs are collected, since collecting everything on busy HMI or historian hosts increases ingest without adding investigative value. Test the agent on a host that runs the plant's control software before rolling it out, and confirm vendor support for the agent on that operating system.

Streams and pipelines for OT, IT and security

Streams and processing pipelines let you route OT, IT and security events to separate destinations and apply different parsing and access rules to each. Keep plant control-network events apart from corporate directory events so that a broad search by an IT analyst does not expose process data. Document the routing rules as part of your network segmentation design, and review them whenever a new site or device class is added.

Index sets with rotation and retention

Index sets control how long each log class is kept and how it is rotated. Create separate index sets for OT events, firewall logs and Windows security events, because each class usually needs a different retention period and a different review schedule. Size storage using daily ingest multiplied by retention days and by 120 percent, as the Graylog architecture guidance advises, and confirm retention periods with your quality, safety and legal teams before you set them.

Event definitions and notifications

Event definitions turn searches into alerts for real-time and historical monitoring, and they can notify PagerDuty, Slack or email. Keep plant alerts for safety-relevant or availability-relevant events on a separate notification path from routine IT alerts, so that a noisy firewall rule does not bury a controller fault. Check which alerting features your chosen edition includes, since correlation and advanced detection depend on Enterprise or Security licensing.

Authentication: LDAP, Active Directory, SAML or OIDC

Graylog Open supports Active Directory and LDAP authentication, along with trusted header authentication. Graylog Enterprise adds Okta, generic OpenID Connect and SAML single sign-on. Choose the method that matches how plant operators and corporate security staff already sign in, and confirm whether plant-floor accounts must stay usable when the corporate directory is unreachable from a remote site.

How to size Graylog storage for plant log volumes

Start with the sizing approach Graylog documents: daily ingest times retention days times 120 percent for log storage, with the message journal at 3 to 5 times daily ingest on SSDs. The formula is simple, but every input in it has to come from measurement. Plants rarely know their real daily volume, because firewall and Windows event volumes vary with shift patterns, remote logins, patch cycles and the number of endpoints actually forwarding. Before you size anything, run the planned collectors against production traffic for a representative period, covering at least one full production cycle, and record the bytes per day arriving from each source class. Firewalls and Windows hosts are usually the two largest contributors, so their numbers should drive the first estimate. Confirm with your own environment and vendors how each device exports logs, since verbose audit settings on Windows and high-rate traffic logging on firewalls can multiply volume without any change to the plant itself.

Next, split the daily volume by log class and assign each class its own retention period. Security events you may need to produce for an investigation or a regulator usually need longer retention than operational or process logs, and the retention you choose sets the disk plan directly. For each class, multiply its daily volume by its retention days and apply the 120 percent factor, then add the totals. Remote sites add a second consideration. If a site loses its link to the central cluster, its forwarders or local buffers must hold events until the connection returns, so the buffer has to cover the longest outage you expect to tolerate, measured in hours at the site's own ingest rate. Those site buffers sit outside the central disk plan and need their own sizing. The message journal on each Graylog node should be sized from the daily ingest figure on fast local SSDs, which keeps the server from losing messages during indexing slowdowns.

Once the disk plan is clear, choose the layout. Graylog recommends Data Node as the search backend, and its multi-node guide describes three Graylog and MongoDB nodes, three Data Nodes on their own cluster and a load balancer for medium to large deployments. Follow that guide for node counts and placement rather than improvising a layout from the storage total. Ask your implementation partner or your vendor to confirm which Graylog version and backend pairing applies to your release, because compatibility requirements differ between versions. Illustrative example: a plant producing a steady daily volume with a 90-day security retention would multiply that volume by 90 and by 1.2 to reach the storage target, then size the journal separately. Replace the illustrative figures with your measured numbers before any purchase or quote.

Which deployment layout fits a single plant, a multi-site group or a restricted OT network

A single plant on one routed network is the simplest layout. Graylog server nodes, MongoDB and the search backend can sit in the plant's data center or a shared IT room, and the IT and OT networks feed them directly through syslog, GELF or Beats inputs. The main design work is separating event sources by network zone so that a noisy OT device cannot crowd out firewall or Windows security events in the same index set.

Components: Graylog server nodes, MongoDB for configuration, and Data Node or self-managed OpenSearch for storage, with a load balancer once you run more than one server node.
Bandwidth: Traffic stays on the local network, so the main limit is ingest rate and journal sizing rather than the link.
Latency: Alerts and searches run close to the sources, which suits near-real-time review of firewall and controller events.
Change control: Input and pipeline changes affect only one site, but plant downtime windows still constrain when server nodes can be restarted.
Scale path: Plan the multi-node layout from the start if the plant may add sites later, since moving an existing single node to a cluster adds work.

Confirm with the network team which VLANs and firewall zones will send logs, which ports they can open to the Graylog server, and whether any OT device can only send to a single destination.

How Graylog for manufacturing evidence maps to NIS2 duties

Manufacturers in NIS2 scope need to show that security measures exist, work, and can be reported on time. The cards below connect each duty to the log evidence a self-hosted Graylog deployment can produce, and to the questions to settle with your own legal and compliance advisers before a build starts.

Article 21 risk management evidence

Article 21 requires in-scope entities to take proportionate technical and organizational measures for network and information security. For a plant, that means showing that OT and IT events are collected, retained and reviewed. Graylog can hold firewall, Windows and industrial system logs in one place, with streams and searches that show who looked at what and when. Check which measures your sector regulator expects, and whether Commission Implementing Regulation (EU) 2024/2690 applies to any part of your business.

Article 23 reporting timelines

Significant incidents must be reported with an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. Those clocks only work if someone detects and triages the event quickly. Define who owns triage across plant IT, OT engineering and the security team, and test whether Graylog event definitions and notifications reach that person outside working hours. Confirm the reporting route with your national competent authority.

Essential and important supervision

Essential entities face ex ante supervision, while important entities face ex post supervision under Articles 32 and 33. Both carry the same risk management and reporting duties. Fines under Article 34(5) reach at least EUR 7 million or 1.4% of worldwide turnover for important entities. Your classification depends on your size and sector, so confirm it with counsel and document the reasoning alongside your log retention and review records.

No certificate, so evidence matters

NIS2 creates no certificate of compliance. National authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. A Graylog deployment does not make you compliant on its own. What it does is produce retention settings, access records, search history and alert logs that you can show an inspector. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports or certifications; independent auditors and authorities make those determinations.

CRA Article 14 vulnerability reporting

For manufacturers of products with digital elements, Article 14 obligations to report actively exploited vulnerabilities and severe incidents apply from 11 September 2026, ahead of the general application date of 11 December 2027. If your firm builds connected equipment or firmware, logs from development, update and vendor-support systems help establish when you became aware of an issue. Confirm with counsel whether your products fall under the regulation and which reporting route applies.

Machinery cybersecurity requirement

The Machinery Regulation applies from 14 January 2027 and adds an essential requirement that machinery be protected so that connecting another device or a remote device does not lead to a hazardous situation. For plants building or integrating machines, this links safety engineering with network controls. Keep records of remote access sessions, connection changes and configuration events so that you can demonstrate the protection was in place. Confirm the conformity route for each machine with your notified body or competent adviser.

Rollout from OT asset inventory to tested alerts

This sequence moves a manufacturing Graylog deployment from agreed scope and an OT asset inventory to tested alerts, runbooks and an incident response exercise. Each phase closes with written acceptance criteria so the plant, IT and security owners sign off on what changed before the next phase starts.

Confirm scope and zones with owners
Plant engineering, OT operations, IT and the security lead agree in writing which sites, production lines, network zones and conduits are in scope, and which systems are excluded. The team records who owns each zone, which change windows production will allow, and which OT systems must not receive new traffic or agents. Acceptance: a signed scope document that names the owner of every zone and the approved change windows.
Inventory log sources for each zone
Working from the OT asset inventory, the team lists every device and application that can produce useful logs, such as firewalls, Windows domain controllers, engineering workstations, historians and remote site gateways. For each source it records the protocol or method the source supports, whether it can send to a remote collector, and who can change its logging settings. Acceptance: a source register reviewed by the OT and IT owners, with unsupported or fragile sources flagged for a separate decision.
Design streams, index sets and retention
Using the source register, the team designs streams that route logs by zone and source type, and index sets that set retention and storage for each group. Storage is sized with the documented formula of daily ingest times retention days times 120 percent, with the message journal sized on SSDs. Retention periods come from the plant's own obligations and are confirmed by the compliance owner, not chosen by the engineers. Acceptance: a written stream and index design with sizing figures reviewed against measured ingest from the first sources.
Deploy the cluster to the documented topology
The platform team installs Graylog server nodes, MongoDB and the Data Node cluster following the installation and multi-node documentation, including the replica set, the load balancer and is_leader set to false on follower nodes. Versions are checked against the compatibility matrix before installation starts. Acceptance: a health check showing all nodes joined, the journal and Data Node cluster green, and a restore test of the MongoDB configuration completed on a non-production copy.
Onboard sources in waves
Sources are connected in waves, starting with firewalls and Windows security events because they carry the highest value for early detection and have well-understood collection paths. Each wave runs inside an agreed change window, and the team confirms that logs arrive, timestamps are correct and parsing matches the expected fields before moving on. Later waves cover remote sites, which may need store-and-forward collectors where bandwidth is limited. Acceptance: for each source, a test event traced end to end and a sign-off from the zone owner.
Build and test event definitions
The security team turns the most important searches into event definitions, covering failed logons, firewall policy changes, and unexpected traffic between zones. Each definition is tested against known events, including replayed or simulated activity agreed with the OT owners, to check that it fires once, routes to the right channel and avoids flooding the on-call team. Alert edition requirements are confirmed before building. Acceptance: a test record for every definition showing trigger, notification and tuning decisions, approved by the security lead.
Run a tabletop against NIS2 reporting windows
The incident response team runs a tabletop exercise with a scenario drawn from the plant's own systems, such as a suspected intrusion through a remote site gateway. Participants use Graylog searches and alerts to establish what happened and when, then work through the early warning, incident notification and final report steps against the 24-hour, 72-hour and one-month windows set by NIS2 Article 23. The exercise records gaps in evidence, roles and handover. Acceptance: a written exercise report with a list of corrective actions and owners, and confirmation from legal or compliance on whether the plant is in scope.
Hand over runbooks and operations
The team delivers runbooks for onboarding new sources, changing streams and index sets, responding to alerts, restoring backups and running support bundles, and agrees who operates the platform after go-live. Any retainer or support arrangement is written down with the owner of each task. Acceptance: runbooks reviewed by the operations team and a documented dry run of one routine task performed by plant or IT staff without vendor help.

How to alert on OT and firewall events without disrupting production

Alerting for OT and firewall events should be designed so that the monitoring load and notification noise never reach the control network itself. Graylog raises alerts from event definitions that run searches against stored data, so the first decision is where those searches run and which streams they read. Keep OT sources in their own streams and index sets, separate from IT firewall and Windows events, so that an event definition for a plant network only evaluates the messages it was written for. Use a separate notification path for OT alerts, routed to people who can act on a process interruption, rather than sending every event to one shared channel where operators learn to ignore it. Confirm with your Graylog edition which notification types and event definition options are available to you, since the Graylog Open product page lists PagerDuty, Slack and email, and some correlation and detection features depend on Enterprise or Security licensing.

Thresholds for OT and firewall alerts should be set from historical data, not from guesses. Run candidate searches over a representative period, such as several weeks of firewall denies or PLC communication errors, and count how often each pattern appears during normal operation, shift changes and maintenance windows. Set aggregation conditions so that an alert fires on a sustained pattern, for example repeated blocked connections from one zone to a controller, rather than on every single message. Document the baseline and the reasoning for each threshold, because an auditor or a plant engineer will ask why a number was chosen. Where you use Sigma rules or prebuilt detection content, review each rule against your own asset list before enabling it, since a rule written for IT endpoints can fire constantly on legitimate industrial traffic.

Any change to alerting that touches OT should be planned around safety and uptime. NIST SP 800-82 Rev. 3 recommends security countermeasures for operational technology while maintaining performance, reliability and safety requirements, so test new event definitions and notifications in a non-production copy first, and schedule enabling them outside critical process windows. The MITRE ATT&CK for ICS matrix can organize the detection content you build, by mapping each event definition to a tactic such as Initial Access or Impair Process Control and showing which tactics you still cannot see. Treat that mapping as a planning aid, not a coverage claim, and confirm with your plant engineers which signals are safe to collect from each controller before you commit to a detection.

What does a Graylog for manufacturing deployment cost and take?

What does Graylog Open cost, and how much are Enterprise and Security?

Graylog Open is free with no volume limits and community support. Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security starts at 18,000 US dollars per year, according to the Graylog pricing page. Both paid editions carry a minimum of 10 GB per day or 100 Graylog Compute Units and are licensed on processed data, with no per-user or per-device fees. Confirm the current figures and the minimum that applies to your daily volume with Graylog before you budget, because plant-level ingest often determines which tier you need. Enterprise adds the data lake, data tiering, the correlation engine and 24/7 support. Security adds SIEM features such as investigations, anomaly detection and prebuilt threat detection content.

What drives the total cost of a manufacturing Graylog deployment?

The main cost components are infrastructure, storage, people and testing time, and each one scales with the plant footprint. Infrastructure covers Graylog server nodes, MongoDB and the Data Node or OpenSearch cluster. Storage follows daily ingest multiplied by retention days and the sizing factor in Graylog's system architecture guidance, so retention for audit evidence usually costs more than the software. People costs cover the engineers who build inputs, parsing, streams and alerts, plus the operators who run the cluster afterward. Testing windows on OT networks add cost because changes must be scheduled around production uptime. Integration count is the last driver: each firewall family, Windows estate, PLC or SCADA source and remote site adds parsing and validation work. Ask any partner to price these components separately in the written scope.

How long does a plant-scale Graylog rollout take?

Duration depends on the number of sites, the number of log sources, how many OT and IT networks must be reached, and how many change windows the plant allows. A pilot on one line or one site is usually much shorter than a multi-site rollout, because each new site repeats network access, collector deployment and validation. Remote sites with limited bandwidth may need forwarders or local buffering, which adds design time. Retention and archiving requirements also extend the schedule, since storage must be sized and tested before the data is relied on. Request a phased plan from any partner that lists each phase, its entry and exit criteria, and the production windows it depends on. Do not accept a single duration without that breakdown.

What does the rollout need from our OT, IT and safety teams?

The work needs three groups with different roles. OT engineers must confirm which controllers, historians and SCADA hosts can send logs, which segments are reachable, and which changes are safe during production. IT security owns firewall and Windows event sources, identity and access rules for the log platform, and the retention policy. Safety and plant operations must approve any change that touches equipment, since NIST SP 800-82 Rev. 3 recommends security countermeasures while keeping performance, reliability and safety requirements in place. Agree on who signs off each change window before the build starts. Without named owners in each group, the schedule usually slips at the first OT change request.

Can our own team build a Graylog deployment for manufacturing?

Yes, if your team has Linux administration, network segmentation and log parsing skills, and time to learn Graylog's index model, pipelines and clustering. Graylog documents package and Docker installs, a multi-node layout with MongoDB as a replica set and Data Node, and a load balancer, so the platform itself is accessible to a capable team. The harder part for most plants is OT access: getting approvals, collectors and parsing rules into controllers and segmented networks without disrupting production. Compare the internal hours needed for that work against a fixed-scope partner engagement, and check whether your team can keep the cluster running afterward. DeployOpen plans, implements, hardens and supports self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with scope agreed in writing first.

What should a written scope from a Graylog partner include?

A written scope should name the sites, the log sources by type and count, the inputs and collectors to be used, and the edition required for each feature. It should list the retention periods and the storage design that supports them, the backup and upgrade approach, and the OT change windows the work depends on. Ask for a clear statement of which items are one-time and which recur, such as retention, support or upgrades. Confirm the acceptance tests, meaning how log flow, parsing and alerting will be verified at each site. Ask who on the partner side is accountable for each deliverable and what the client team must provide. Finally, check that the document states what is excluded, including any compliance evidence that an independent auditor would need to assess.

Does the SSPL-1.0 license affect how we use Graylog in our plants?

Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0), which the Graylog license file describes for releases from 4.0 in 2020 onward. SSPL-1.0 is not an OSI-approved open source license, so it may not match internal policies that require OSI-approved licenses. Internal use inside your own plants is the common case, but the license terms should be reviewed by your legal team before you deploy, especially if you offer log services to affiliates, suppliers or customers. Some inputs and features also need an Enterprise or Security license, so confirm which ones your design depends on before the build starts.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted Graylog inside your own infrastructure, whether that is your data center, cloud accounts or a segmented plant network. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

We map which OT, IT, firewall and Windows sources must reach Graylog and where each one sits.
We confirm the retention and review obligations your sites, auditors and any in-scope NIS2 duties require.
We agree sizing, Data Node and MongoDB topology, and which Enterprise or Security features are in the written scope.

How we build

We deploy Graylog server nodes, MongoDB and Data Node in your environment, following the multi-node pattern Graylog documents.
We configure inputs, streams, processing pipelines and index sets for each plant, tested against sample events from each source.
We build event definitions and notifications for agreed use cases, and test them against historical and live data before go-live.

How we hand over

We document the architecture, data flows, source inventory, retention settings and alert logic for your operations team.
We run a handover session covering search, dashboards, index rotation, journal monitoring and backup procedures.
We deliver runbooks for remote site collectors, including what to check when bandwidth is limited or a forwarder stops sending.

How we support

Ongoing support, version upgrades and continuous testing are available as retainers after the initial handover.
A retainer can cover planned Graylog upgrades, since documented breaking changes in parsing and APIs need planning per release.
We can help you prepare evidence of log collection and review for compliance assessments, though independent auditors issue any formal findings.