A process historian records time-series data from a plant: sensor readings, alarms, events and process values. It is one of the most valuable data sources in an industrial environment, which is exactly why analytics, reporting and corporate teams want access to it.
The tension is obvious. The historian sits inside a protected OT zone, and giving outside teams two-way access to it punches a hole in that zone. One-way replication resolves the tension by sending the data out without offering a path back in.
01Key takeaways
- 01
A historian holds the time-series production data that analytics and reporting teams most want.
- 02
Two-way access to the primary historian exposes the OT zone to whoever can reach it.
- 03
One-way replication exports selected historian data to a reporting or analytics environment without an inbound path.
- 04
Replicating only the needed tags reduces both data volume and the temptation to query back for context.
- 05
The pattern maps cleanly onto IEC 62443 zones and conduits as a publication-only conduit out of the OT zone.
02What a historian is and why everyone wants the data
A historian is a database optimized for time-series process data. It captures what happened in the plant over time and is used for troubleshooting, optimization, quality analysis and reporting.
Because that data drives decisions well beyond the plant floor, demand for access comes from analytics platforms, corporate reporting, data science teams and sometimes external partners. Each request, if granted as direct access, becomes a new path into the OT zone.
The historian is the data everyone wants, in the place no one outside should be able to reach.
03The risk of two-way historian access
Granting outside systems direct, two-way access to the primary historian means the OT zone now trusts those systems and the networks they sit on.
- Each external consumer becomes a potential entry path into the protected zone.
- Credentials used for historian queries become targets that lead inward.
- A compromise of an analytics platform can pivot toward the plant through the query path.
- The boundary's security now depends on the hygiene of every system allowed to connect.
The more valuable the data, the more consumers want it, and the more inbound paths accumulate. Direct access does not scale safely.
04One-way replication patterns
One-way replication inverts the relationship. Instead of letting consumers reach in, the OT zone pushes a copy of the data out to a replica that lives outside the protected boundary.
- Replica historian
- A copy of selected historian data maintained outside the OT zone, where analytics and reporting connect freely without touching the primary.
- One-way conduit
- A boundary that enforces direction, so data flows from the primary historian to the replica but no traffic returns through that path.
- Consumers hit the replica
- All outside queries go to the replica, so the primary historian never sees external connections at all.
06Mapping to IEC 62443 zones and conduits
In IEC 62443 terms, the primary historian sits in a higher-trust OT zone, and the replica sits in a lower-trust zone. The replication path is a conduit, and one-way replication makes it a publication-only conduit.
For teams designing this boundary, an AIRGAPNET controlled connectivity pattern can be evaluated alongside a data diode or unidirectional gateway, depending on whether the conduit should be permanently one-way or offline by default and opened on a schedule.
Either way, the design keeps the control honest: the conduit carries only what the data flow requires, in the direction the architecture allows.
07Historian replication checklist
- Which tags and aggregation levels do outside consumers actually need?
- What enforces direction on the replication conduit?
- How is buffering and integrity handled so the replica detects gaps?
- Do all external consumers connect to the replica, never the primary?
- How does the design map to the relevant IEC 62443 zones and conduits?
- Can the team prove what was replicated and when?
08Closing thought
Historian data is too useful to lock away and too sensitive to expose through direct access. One-way replication is the design that satisfies both: the data leaves, the consumers are served, and the OT zone never accepts a connection from outside.
Decide what the replica needs, push it one way, and point every consumer at the copy. The plant keeps its boundary while the rest of the business gets its data.
FAQFrequently asked questions
What is OT historian replication?
OT historian replication copies selected time-series data from a primary process historian inside the OT zone to a replica outside it. Analytics and reporting teams query the replica, so the primary never accepts external connections.
Why not give analytics teams direct access to the historian?
Direct, two-way access makes every external consumer a potential path into the protected OT zone. Credentials and analytics platforms become targets that lead inward, and the boundary's security comes to depend on the hygiene of every connected system.
How does one-way historian replication work?
The OT zone pushes selected historian data outward across a boundary that enforces direction, maintaining a replica outside the zone. No traffic returns through that path, and all outside queries hit the replica.
Should you replicate the whole historian?
Usually not. Exporting only the tags and aggregation levels consumers need reduces data volume, limits what leaves the zone, and removes the temptation to open a query path back for missing context.
How does this map to IEC 62443?
The primary historian sits in a higher-trust zone and the replica in a lower-trust zone, with the replication path as a conduit. One-way replication makes it a publication-only conduit out of the OT zone.
SRCSources of record
Let the data out, not the consumers in
Serve analytics from a replica, never the primary.
Push selected historian tags one way to a replica outside the OT zone, so reporting and analytics get their data while the plant keeps a boundary with no inbound path.