Control networks have been kept closed so that equipment never stops. Information systems have been opened up so that management can decide faster. OT IT convergence is the work of joining those two worlds, and it has become an unavoidable topic the moment a plant starts looking at smart factory initiatives or predictive maintenance. Get the sequence wrong, however, and you invite both unplanned downtime and a security incident at the same time. This article works through the whole picture in order — how OT actually differs from IT, the three barriers that stop integration projects, the current publication status of IEC 62443 and the multi-nation joint guidance released in January 2026, and the practical steps for making it happen at a plant in Thailand.
What OT Is — Defining the Difference from IT on the Shop Floor

Start by aligning on vocabulary. If an internal discussion begins while the terms are still fuzzy, two people will say “the factory system” and mean completely different things, and neither the requirements nor the budget will ever line up.
OT Is the Technology That Keeps Equipment Running
OT stands for Operational Technology. It is the collective term for the technology that physically moves, monitors, and stops equipment inside a plant.
Concretely, that means the PLCs handling sequence control, the SCADA systems that aggregate the status of multiple machines for monitoring and operation, the DCS platforms used in process plants, the HMIs that operators touch on the floor, and the sensors picking up temperature, pressure, vibration, and current. Robot controllers and the dedicated control hardware embedded in inspection machines are part of OT as well.
What all of these share is that the thing they act on is not information but physical phenomena. When a PLC flips one output, a cylinder actually moves, a valve actually opens, a line actually stops. The fact that the result of a computation appears directly in the real world is exactly what produces the difference in security philosophy discussed later.
SCADA sits on the boundary between monitoring and operation, which makes it the part of the OT side most likely to become a touchpoint with IT. Product selection criteria and how to think about five-year total cost are covered in detail in What Is SCADA in 2026 — The Write Boundary That Multiplies Cost 2.5x, so if you are currently reviewing your monitoring layer, it is worth reading alongside this piece.
IT Handles Information, OT Handles Physical Phenomena
IT, or Information Technology, is the technology for storing, processing, and transmitting information. In a manufacturing context that covers ERP, production management systems, MES, accounting systems, mail and file servers, and the network and server infrastructure they all run on.
When something breaks in the IT world, the damage is generally contained within information. If one server goes down, work stops, but nobody gets hurt at that moment. That is precisely why the standard IT response works — take it offline, investigate the cause, apply a fix, then bring it back.
In the OT world that assumption does not hold. Deciding to stop a running line is itself a decision about the production plan, the delivery date, and unit cost. Some processes, such as heat treatment furnaces or chemical reaction vessels, cannot be interrupted midway without risking damage to the equipment or a genuine safety hazard.
The Order of Priorities Is Exactly Reversed
The most fundamental difference between OT and IT is not the type of hardware involved. It is the order of priorities. IT puts confidentiality first, while OT puts availability first — meaning, above all, do not stop.
Laying the difference out in a table makes it clear why governing both under a single policy is so hard.
| Dimension | IT | OT |
|---|---|---|
| Top priority | Confidentiality, then integrity, then availability | Availability, then integrity, then confidentiality |
| First response to an incident | Isolate and shut down the affected system | Keep producing while determining the scope of impact |
| Update frequency | Typically scheduled patching every week to every month | Typically bundled into one or two planned shutdowns per year |
| Equipment lifespan | Typically replaced on a four to six year cycle | Typically expected to run for ten to twenty years or more |
| Owning department | Information systems | Production engineering, maintenance |
| Reach of a failure | Data and business processes | Equipment, product quality, worker safety |
The intervals and frequencies in the table reflect the general pattern we see on customer sites, and they vary by industry and by equipment type. With that caveat, the two rows that generate the most friction in practice are “update frequency” and “equipment lifespan”. Seen from the IT department, dozens of factory PCs still running a ten-year-old operating system are an unacceptable open vulnerability. Seen from the OT department, that same PC is the runtime environment for the proprietary software bundled with an inspection machine, and the moment the OS is updated the machine might become unusable. Both departments are saying something correct from where they sit.
Why Integration Can No Longer Be Postponed
With the definitions aligned, the next question is why this integration has stopped being optional. The pressure is not coming from the shop floor. It is coming from the market and from the boardroom.
A USD 151 Billion Market by 2030, Growing 14.6% a Year
Research from The Business Research Company projects that the OT/IT convergence market will reach USD 151 billion by 2030, at a compound annual growth rate of 14.6%.
That figure says that investment aimed specifically at integration is accumulating continuously and globally. Read the other way around, it also says that equipment and services built on the assumption of integration are becoming the default. You can still defer the decision on your own terms today, but within a few years there is a good chance the equipment you procure will simply arrive with connectivity assumed in its specification.
Manufacturers Executing Industry 4.0 Spend 3.2 to 4.1% of Revenue on IT
The gap shows up in spending levels too. Private-sector benchmark research estimates that manufacturers actively executing an Industry 4.0 strategy commit 3.2 to 4.1% of revenue to IT budgets, against 1.8 to 2.4% for conventional manufacturers.
The multiple is the part worth noticing. That is roughly a 1.7 to 1.8 times difference, and it is not a gap that better cost discipline closes. It is more accurate to say the two groups are not doing the same thing at different efficiencies — they are doing different things.
One caution before you put this number in an internal deck. There is no causal link where raising the budget ratio produces results. That level of spending becomes meaningful because the organisation is capable of operating an integrated system. Matching the ratio without building that capability just produces more systems nobody uses.
The Structural Gap Between Management and the Shop Floor
Japanese manufacturing carries one additional, specific problem. Hitachi Solutions has pointed out that Japanese manufacturers suffer from a structural gap between management and the production floor. Executives issue instructions while looking only at numerical data, and the floor reports upward without visibility of the whole picture. Within that disconnected structure, data being filtered and slanted on its way up can become fertile ground for misconduct such as falsified quality records.
We read that observation as a reason not to treat OT IT convergence as a purely technical topic. The goal is that what happens on the floor reaches management unprocessed, and that the assumptions behind management decisions are shared back with the floor. Building that pathway is the objective. Collecting data is not.
In practical terms, the fork in the road looks like this. If the collected data is aggregated monthly into a report, the gap does not close. The gap only starts closing when an abnormality reaches every relevant person simultaneously and unprocessed, at the moment it occurs. Both of those are described as “collecting data”, and they produce entirely different outcomes.
The Three Barriers to OT IT Convergence

Even when the direction is agreed, real projects stall at three barriers. Only the last of the three is technical. The two that come first are not.
Barrier 1 — Availability-First Versus Confidentiality-First
The barrier most often identified as the largest is the clash in values between the security the IT department prioritises and the availability — not stopping — that the OT department prioritises.
The conflict surfaces reliably in concrete situations. IT wants to deploy the company-wide asset management agent onto factory PCs. OT objects, because nobody can guarantee the agent will not affect the response time of the machine control software. IT wants to run a vulnerability scan across the whole network. OT objects, citing a past incident where an older PLC became unresponsive purely from receiving scan packets.
The important thing is not to frame this conflict as one side failing to understand the other. The two departments are looking at different risks. IT is looking at the risk of information leaking. OT is looking at the risk of the line stopping. Both risks are real.
The recommended remedy is to build a cross-functional team with shared KPIs. “Shared KPIs” here does not mean forcing everything into one department’s vocabulary. It means putting both sets of metrics on one board and making a single team accountable for both.
Barrier 2 — The Organisational Divide and Where the Budget Comes From
The second barrier is organisational. At most Japanese-owned plants, OT-side capital investment runs through the production engineering department or the plant budget, while IT-side system investment runs through the head office information systems budget.
That split creates a difficulty specific to integration projects. The benefit of integration shows up at the plant, while the cost of the security controls that make integration safe lands on the information systems department. Benefit and cost end up on separate ledgers. From the perspective of whoever has to raise the approval request, they are spending their own budget to produce another department’s result, and it never rises up the priority list.
The practical countermeasure is to establish a separate budget line for the integration project from the outset. Force it into either department’s existing annual budget and something will get cut — and what gets cut is almost always the security work, because its benefit is hardest to express as a number.
Barrier 3 — Data Formats, and Sorting Out MES Versus ERP
Only the third barrier is technical. On the OT side and the IT side, the shape of the data, the update cycle, and the definition of meaning are all different.
OT data is time-series values generated every second or every millisecond. Equipment number, timestamp, measured value, repeating endlessly. IT data — particularly the data ERP handles — is records grouped by transaction or by work order. It is finalised daily or per order, and it carries meaning as an amount or a quantity.
MES is the layer that bridges the two. To sort out the difference between MES and ERP, ERP is the system that plans and records enterprise-wide resources such as sales orders, purchasing, inventory, cost, and accounting, whereas MES is the system that handles manufacturing execution itself — dispatching work instructions, collecting actuals, recording quality, and maintaining traceability. In terms of time granularity, ERP moves at the level of a day or an order, MES at the level of an operation or an individual unit.
The failure we see most often on site is deploying both without first deciding where that boundary sits, and ending up holding the same actual production data twice. Because nobody decided which number is authoritative, every month-end variance triggers an investigation. Where to draw the line, and what that decision does to cost, is covered concretely in MES Implementation in Thailand — Cost, Comparison and the ERP Boundary, so if you are still at the stage of evaluating MES, reading that first is the natural order.
Why the Factory Data Logger Becomes the Bridge
The practical way over the third barrier is to let a factory data logger or edge gateway act as the bridge.
A data logger is a device that records equipment signals and sensor values at a fixed interval. Its role in a plant goes beyond simply keeping a record. Because it can be placed in a position that takes no part in control itself, it creates an outlet for values to leave the OT side without touching the existing PLC or SCADA configuration.
That property is what matters. From the OT side, control logic is untouched, so there is no risk of equipment behaviour changing. From the IT side, what arrives is clean time-series data rather than raw signals. This is one of the few positions that satisfy both sets of requirements at once.
Staged modernisation guidance stresses the importance of adding secure IoT gateways and edge computing rather than replacing ageing equipment, and this is what that looks like in concrete form. Equipment installed on the assumption of a ten-year-plus service life cannot realistically be replaced just to enable integration. The mindset has to be leaving the equipment alone and adding an outlet on the outside.
The Real State of OT-Side Security Risk
Pursuing integration means creating a pathway into an area that was previously closed. That makes it necessary to pin down where the risk actually stands, in numbers.
3,300 Organisations Hit in 2025, Manufacturing Over Two Thirds of Victims
According to the annual report published by OT security specialist Dragos on 17 February 2026, 3,300 industrial organisations worldwide were hit by ransomware in 2025, and manufacturing accounted for more than two thirds of all victims.
The increase did not begin that year. The previous edition reported 1,693 ransomware attacks against industrial organisations in 2024, up 87% year on year, of which 1,171 attacks — 69% — targeted manufacturing. The attacker population is growing too. The number of ransomware groups targeting industrial organisations rose from 80 in 2024 to 119 in 2025.
The natural reading of why manufacturing gets selected is the size of the downtime cost rather than the ability to pay. The more precisely an industry can calculate its loss from a single day of stopped production, the more pressure there is to restore fast. From the attacker’s perspective, that is a counterparty likely to settle.
Visibility Is the Difference Between 42 Days and 5 Days
The same report contains a figure that connects directly to the subject of this article. Ransomware dwell time in OT environments — the period from intrusion to detection and containment — averaged 42 days across the industry. Organisations with thorough visibility of their OT environment detected and contained in an average of 5 days.
That gap is best read as a difference in whether you can see, not in how thick your defences are. And making an OT environment visible is, by definition, delivering OT-side data into the IT-side monitoring stack. OT IT convergence is an initiative to raise productivity and, at the same time, the foundation for stopping damage early.
Judging by those numbers, the position of deferring integration itself on security grounds has become hard to sustain. Choosing not to integrate is also choosing to stay blind.
Incident Counts in Japan and the IPA Threat Ranking
It is worth checking the situation in Japan as well. In the IPA’s published “10 Major Security Threats 2026”, ransomware attacks ranked first among threats to organisations.
For actual incident counts, the National Police Agency reported 226 ransomware cases for the full year 2025. That figure spans a wide range of industries, not manufacturing alone.
That 226 needs careful reading. It is the number of cases reported to police, and the real total is reasonably assumed to be higher. It is equally dangerous to look at the count alone and conclude that the odds of being hit are low. What should drive the decision is not the probability of occurrence but the magnitude of impact — how much of your production stops if it happens once.
The thinking behind controls specific to OT environments, and how to work through them in practice at a plant, is set out systematically in OT Security for Manufacturing in Thailand: 2026 Guide, so keep that one to hand when you reach the stage of designing specific countermeasures.
Two Foundations — NIST SP 800-82 Rev.3 and ISA/IEC 62443
When designing countermeasures, the reliable approach is to build on existing international standard frameworks. NIST SP 800-82 Rev.3, published in September 2023, and ISA/IEC 62443 both function as international standard frameworks for OT security.
The two do not compete. The former is an overall OT security guide that systematically presents the concepts and the control areas. The latter is a family of standards specific to industrial automation and control systems, defining the zone and conduit concept and the concrete requirements placed on devices and systems. In practice, you set overall policy using the former and specify device and system requirements using the latter.
IEC 62443 and IIoT — Know the Difference Between a PAS and an IS
On the IEC 62443 side, work on IIoT has been progressing. IEC PAS 62443-1-6:2025 was published on 19 December 2025. The part is titled “Application of the 62443 series to the IIoT”, and the document sets out how to apply a series originally built around closed control networks to architectures where sensors connect directly to the cloud.
One practical caution here. This was published as a PAS, a Publicly Available Specification, not as an IS — a formal International Standard. A PAS is a specification published early within the standardisation process and should not be treated with the same weight as a formal International Standard. When you reference it in internal standards documents or procurement specifications, we recommend stating that status explicitly.
The part that defines requirements on the devices themselves is IEC 62443-4-2. As of writing, the current version is Edition 1.0, published on 27 February 2019, and it specifies technical security requirements for components — embedded devices, host devices, network devices, and software applications. The stability date shown on the official IEC page is 2027, and as of writing no publication date for a new edition has been announced. Writing “compliant with the latest edition” into a specification without confirming which edition has actually been published leads to conflicting interpretations later.
The gateways and data loggers you introduce as bridges are exactly the class of device IEC 62443-4-2 covers. Confirming firmware signature verification and the remote update mechanism with the vendor at the procurement stage avoids having to swap the hardware out afterwards.
The January 2026 Joint Guidance and the Outbound Connection Principle
There has been one more development that shapes practical design. In January 2026, “Secure Connectivity Principles for Operational Technology” was released, led by the UK NCSC with participation from CISA and the FBI in the US, ASD in Australia, the Cyber Centre in Canada, BSI in Germany, NCSC in the Netherlands, and NCSC in New Zealand. It is a joint document from eight agencies across seven countries, presenting eight principles for designing, protecting, and managing connectivity to OT environments.
The principle with the most direct implementation consequences is that all connectivity to an OT environment should be outbound connections initiated from inside the OT environment. This is the push-only approach — rather than opening a connection inward from the outside, the OT side pushes the data it needs to send outward.
The reason the direction matters is that if no inbound pathway exists, the possibility of that pathway being abused disappears entirely. The thinking is not about narrowing down who is allowed to connect through authentication. It is about not creating an entrance at all.
The practical impact is specific. An architecture where a cloud analytics platform reaches in to connect to a factory database does not comply with this principle. It has to change to an architecture where a gateway on the plant side sends data out to the cloud. In the same way, remote maintenance arrangements where an external engineer connects directly to a machine come up for review under this principle.
From the Purdue Model to the Zone Model
The Purdue model always comes up when OT network design is discussed. As of 2026, though, the way it is used is changing.
A Hierarchical Model Proposed in 1992
In 1992, Theodore J. Williams and colleagues proposed the Purdue model, formally the Purdue Enterprise Reference Architecture. It organises everything from equipment up to business systems into layers, and it later became the basis for the zone and conduit model in ISA-99 and IEC 62443.
The model stayed in use so long because its principles — control communication between layers, protect the layers closest to the process most heavily, and mediate the boundary with enterprise systems — captured something essential about OT security.
The 2026 Verdict Is “Neither Obsolete Nor Sufficient”
As of 2026, the assessment is that the Purdue model is neither obsolete nor sufficient.
The reason is that the assumptions behind the layer structure increasingly fail to match reality. IIoT sensors send data directly to the cloud, remote maintenance connections link external engineers straight into systems, and digital twins pull raw data from lower layers. In those architectures, the assumption that communication climbs the layers one at a time no longer holds. A layer model on its own cannot describe what is actually there.
That is not an argument for discarding the Purdue model. The current practical form is to keep it as a shared frame of reference while doing the actual segmentation in detail with IEC 62443 zones and conduits.
Group by Protection Need, Not by Layer
Within IEC 62443, the shift is towards a zone model that groups assets by protection need rather than by layer.
Put another way, where the Purdue model asks “which layer is this asset in”, the zone model asks “what happens if this asset is compromised”. Rather than physical or network position, assets whose loss produces impact of similar magnitude go into one zone. The communication paths connecting zones are defined as conduits, and only those paths are strictly controlled. That is the zone and conduit idea.
Where this shift pays off in practice is precisely the OT IT convergence scenario. As integration proceeds, communication that crosses layers necessarily increases. Judged by layer, every one of those flows becomes an exception. Judged by protection need, each new pathway can be defined as a conduit joining one specific zone to another, and managed at that granularity.
How to Approach OT IT Convergence — Four Steps of Staged Modernisation

From here on, the actual sequence. Rather than rebuilding everything at once, structure the work on the assumption of stages.
Step 1 — Inventory Assets and Design Zones
The first task is not selecting new equipment. It is understanding what you already have.
The inventory covers PLCs, SCADA, HMIs, industrial PCs, the PCs attached to inspection machines, network equipment, and the communication devices that equipment vendors installed for their own maintenance access. That last item is the one most often missed. It is not unusual to find that a vendor installed a router for remote maintenance at the time of delivery, and its existence never made it onto the plant’s asset register.
Once the inventory exists, write down for each asset what happens if it is compromised. Does the line stop? Are quality records lost? Does a safety function stop working? Group together the assets whose impact is similar in nature and magnitude, and you have the raw form of your zones.
Skip this step and start by installing equipment, and later you will not be able to answer the question of which zone a given device belongs to — which means starting over.
Step 2 — Push Data Out One Way with a Data Logger or Edge Gateway
Next, create the pathway that takes data out of the OT side. What has to be respected here is the outbound connection principle described earlier.
The architecture places a data logger or edge gateway inside the control network and permits only the direction that sends data up to the higher-level network. Opening a connection from the upper side down into OT is not permitted. Fixing that direction is the core of this architecture.
On the data itself, we recommend not aiming for everything from the start. Begin with the small number of items that connect directly to management decisions. Equipment running and stopped state, stop reason codes, production count, and quality judgement results. Those four categories alone make two fundamental indicators — utilisation rate and defect rate — visible in real time.
Narrowing the item list keeps traffic volume low and limits the load on the existing network. More importantly, it shortens the time to first operation. Projects where the benefit takes a long time to appear lose priority partway through and stop.
Step 3 — Build a Unified Data Model and Fix the MES and ERP Roles
The third step gives shared meaning to the data you have collected. The emphasis placed on building a unified data model connecting ERP, MES, CRM, and shop floor systems refers to this step.
What has to be decided concretely is which system holds the authoritative master for each key entity — equipment, item, work order, lot, operator, defect reason. It is extremely common to find that equipment numbering follows a different scheme in SCADA, in MES, and in ERP. Collect data while that is still true and reconciliation will keep consuming manual effort indefinitely.
At the same time, fix the division of roles between MES and ERP in a written document at this stage. Which actual production data is finalised in MES, and at what point does it pass to ERP. Conversely, what passes from ERP to MES. Run both systems while that remains ambiguous and duplicate entry and mismatched figures become permanent features.
Step 4 — Apply Zero Trust and Operate a Cross-Functional Team
The last step is the structure that keeps it running. On the technical side, applying zero trust across both the IT and OT networks is emphasised. The idea is not to treat “the connection came from the internal network” as grounds for trust, but to authenticate and authorise per communication.
On the organisational side, build the cross-functional team with shared KPIs described earlier. The practical point, in our view, is to place at least one full-time member on that team. A team where everyone is part-time stops functioning the moment their primary duties get busy.
For the metrics the team reviews, put the production-side utilisation rate and defect rate on the same list as the security-side asset register coverage and open vulnerability count. Handling both in a single meeting makes it much harder for decisions to favour one side at the expense of the other.
Points Specific to OT IT Convergence at Thai and ASEAN Sites
From here, closer to the ground in Thailand. Compared with integration in Japan, a Thai site brings several conditions of its own.
BOI’s 2026 Investment Incentives and Automation and Robotics
Start with the regulatory side. On 15 January 2026, the Thailand Board of Investment (BOI) announced new investment incentives for 2026. Alongside strategic industries including five fields — BCG (bio, circular, and green economy), EV and battery, semiconductors and advanced electronics, digital and AI, and international business centres — automation and robotics is also identified as one of the priority areas.
If you are considering an integration project at a Thai site that involves capital equipment, it is worth checking early whether it falls within this framework. That said, the scope and conditions of incentives are defined in detail per measure and are updated from time to time. This article describes only the general direction, so any determination of eligibility must be based on the official current BOI announcements and confirmation with a qualified adviser.
Building the Team with Local Engineers
Harder than the technical side is the organisational one. Integration cannot be operated from Japan on a business-trip basis. Adding a data logger, changing the network configuration, first-line triage when something goes wrong — all of these require someone on site who can judge and act.
In building the team with local engineers, what we find genuinely effective in practice is drawing a clear line between “monitoring” and “changing”. The local team handles monitoring day to day, while any work that changes the configuration goes through a documented procedure and an approval process. Without that line, well-intentioned on-the-spot setting changes accumulate, and a few months later nobody can explain the current configuration.
The other point is the language of the documentation. Zone definitions, the connection allow-list, the emergency escalation path. These have to be prepared in a language local staff can read and understand. Material produced in English only does not get referenced in an emergency.
What to Settle with Japan Headquarters in Advance
One issue specific to Japanese-owned sites is the relationship with head office. Once integration makes local production data visible, a discussion about how much of that data to share with headquarters is guaranteed to follow.
Our practical view is that this has to be agreed before the technical architecture is decided. Trying to settle it afterwards means changing a network configuration and cloud placement that already exist.
Four points specifically worth settling first. Whether head office reads local raw data directly, or receives only results aggregated locally. Whether data is stored inside Thailand, or on head office or third-country cloud infrastructure. Whether decision authority when an abnormality occurs sits locally or at head office. And whether a pathway is created for head office to connect into systems at the Thai site.
That last point can collide directly with the outbound connection principle described earlier. If the head office information systems department already runs a company-standard remote access mechanism, whether it can be applied as-is to an OT environment is a separate judgement.
A Checklist to Review Before Starting
Here is everything above reduced to check items you can take straight into an internal meeting.
- Have you produced an asset register of the OT assets in the plant, including maintenance communication devices installed by equipment vendors?
- For each asset, have you written down what happens if it is compromised, and grouped assets by the nature of that impact?
- Is the pathway that takes data out of the OT side an outbound connection initiated from the OT side?
- Have you inventoried every pathway that opens a connection from outside into the OT environment, including remote maintenance?
- Have you narrowed the initial data items to a small set such as running state, stop reason, production count, and quality judgement?
- For key entities such as equipment, item, work order, and lot, has exactly one system been designated as the authoritative master?
- Is it documented which of MES and ERP finalises what, and when the handover happens?
- For gateways and data loggers being newly introduced, have you confirmed firmware signature verification and the remote update mechanism with the vendor?
- Is there a standing meeting where production-side metrics and security-side metrics appear on the same list?
- Does that meeting have a dedicated owner rather than someone doing it alongside another role?
- Are zone definitions and the emergency escalation path available in a language local staff can read?
- Have the four points on data sharing scope, storage location, decision authority, and connection pathway been agreed with head office in advance?
If you start selecting equipment before you can answer yes to the top four, you will have to revisit the architecture after deployment. Conversely, if you go live without settling the bottom four, you will lose time to adjustments once operation has already begun.
Frequently Asked Questions
What is OT?
OT stands for Operational Technology. It is the collective term for the technology that physically moves, monitors, and stops equipment in a plant, covering PLCs, SCADA, DCS, HMIs, various sensors, and industrial robot controllers. The biggest difference from IT, which handles information, is that the result of processing appears directly as movement in the real world. That is why the baseline mindset places availability — not stopping the equipment — above confidentiality.
What is the difference between MES and ERP?
They differ in what they handle and in time granularity. ERP plans and records enterprise-wide resources such as sales orders, purchasing, inventory, cost, and accounting, working with data finalised at the level of a day or a work order. MES handles manufacturing execution itself, covering the dispatch of work instructions, collection of actuals, quality records, and traceability at the level of an operation or an individual unit. What matters in practice is not the either-or choice of which to deploy, but deciding in advance which actual production data is finalised in MES and at what point it passes to ERP. Run both without settling that and you will hold the same actuals twice, making month-end variance reconciliation a permanent task.
What is a data logger used for in a factory?
It is a device that records equipment signals and sensor values at a fixed interval, but in the context of OT IT convergence it is used as the outlet that extracts data from a position taking no part in control. Because it does not touch the control logic itself, it can be installed without changing the existing PLC or SCADA configuration, avoiding any risk of equipment behaviour changing. This device is the centrepiece of a staged approach that achieves connectivity without replacing ageing equipment. When introducing one, we recommend confirming firmware signature verification and the safety of remote updates with the vendor.
What is the first step in OT IT convergence?
Not equipment selection and not product comparison, but an asset inventory. Register every OT asset in the plant, including the communication devices equipment vendors installed for maintenance, and write down what happens if each one is compromised. That information becomes the foundation for zone design and the basis for deciding where connections may originate and in which direction data leaves. Skip the inventory and start by installing equipment, and rework of the architecture becomes likely later.
Is the Purdue model no longer usable?
It has not become unusable, but the 2026 assessment is that it is no longer sufficient on its own. In architectures where IIoT sensors send data straight to the cloud and remote maintenance links external engineers directly into systems, situations arise where the assumption that communication climbs layers in order does not hold. At the same time, the underlying principles — control communication between layers, protect the layers close to the process heavily, and mediate the boundary with enterprise systems — remain valid. The practical form is to use the Purdue model as a shared frame of reference while doing the actual segmentation with IEC 62443 zones and conduits, based on protection need rather than layer.
Does pursuing integration increase security risk?
Since you are creating a pathway, doing nothing else would increase risk. What matters in practice, though, is that the risk of not integrating is not zero either. Plants without integration still have pathways — the equipment vendor’s maintenance line, data carried out on USB drives, old PCs missing from the asset register. Inventorying assets, defining pathways, and fixing their direction as part of an integration project is, if anything, the work of making visible the risks you were not aware of. In our view, the decision is not whether to integrate, but whether pathways are managed as known ones or left in place as unknown ones.
Summary
Here are the key points covered in this article.
- OT is the technology domain that moves physical equipment. Where IT puts confidentiality first, OT puts availability — not stopping — first. That difference in priorities is the root of what makes integration hard
- The OT/IT convergence market is projected to reach USD 151 billion by 2030 at a compound annual growth rate of 14.6%. Private-sector estimates put IT budgets at manufacturers executing Industry 4.0 at 3.2 to 4.1% of revenue, against 1.8 to 2.4% for conventional manufacturers
- Japanese manufacturing carries a structural gap between management and the production floor, and data being filtered and slanted on its way up has been identified as potential fertile ground for misconduct
- Three barriers block integration, appearing in this order — the difference in security philosophy, the organisational barrier of split budget ownership, and the data format barrier. Only the last is technical
- MES and ERP differ in what they handle and in time granularity, and the practical crux is deciding in advance which actuals MES finalises and when they pass to ERP
- Factory data loggers and edge gateways can extract data from a position that takes no part in control, which makes them the centrepiece of staged modernisation that achieves connectivity without replacing ageing equipment
- Dragos reported 3,300 industrial organisations hit by ransomware worldwide in 2025, with manufacturing more than two thirds of victims. Dwell time in OT environments averaged 42 days across the industry against 5 days at organisations with thorough visibility. In Japan, ransomware ranked first for organisations in the IPA “10 Major Security Threats 2026”, and the National Police Agency reported 226 cases for full-year 2025
- NIST SP 800-82 Rev.3, published in September 2023, and ISA/IEC 62443 form the international standard foundation, and IEC PAS 62443-1-6:2025 setting out application to the IIoT was published on 19 December 2025. IEC 62443-4-2, which defines device requirements, is at Edition 1.0 published on 27 February 2019 as of writing
- In January 2026, eight agencies across seven countries led by the UK NCSC jointly published a document presenting eight principles, including that all connectivity to an OT environment be an outbound connection initiated from the OT side
- The Purdue model proposed in 1992 is assessed in 2026 as neither obsolete nor sufficient, and the practical form is to use it as a shared frame of reference while doing the actual segmentation with IEC 62443 zones and conduits based on protection need
- The approach runs in four stages — asset inventory and zone design, one-way data extraction via a data logger, a unified data model with fixed MES and ERP roles, and zero trust with a cross-functional team in operation
- At Thai sites, automation and robotics is one of the priority areas in BOI’s 2026 investment incentives, while the practical dividing lines are the division of roles with local engineers, documentation in the local language, and advance agreement on the scope of data sharing with head office
The first thing to do is not comparing products and not securing budget. It is getting as far as an internal asset register of the OT assets in the plant, with a written note of what happens if each one is compromised. Whether or not that list exists completely changes how concrete the proposals you subsequently receive will be.
TOMAS TECH supports shop floor DX for Japanese manufacturers operating in Thailand, including the PEGASUS production management system. On OT and IT integration we also take on the earlier questions — where to begin listing assets, how to reconcile head office remote access policy with the local OT environment. It is perfectly fine to reach out while you are still at the consideration stage and nothing has been decided internally, so please get in touch through our contact page.
References
- CISA – Secure Connectivity Principles for Operational Technology (OT)
- The Business Research Company – IT or OT Convergence Global Market Report
- NIST – SP 800-82 Rev.3 Guide to Operational Technology (OT) Security
- IPA – 10 Major Security Threats 2026
- INTERNET Watch – National Police Agency summary of the 2025 cyber threat landscape
- IEC Webstore – IEC PAS 62443-1-6:2025 Application of the 62443 series to the IIoT
- IEC Webstore – IEC 62443-4-2 Edition 1.0 Technical security requirements for IACS components
- Dragos – 2026 OT Cybersecurity Year in Review
- Beacon Security – The Purdue Model in 2026
- Hitachi Solutions – On the convergence of OT and IT connecting management and the production floor
- Alvarez and Marsal – Thailand’s Renewed BOI Incentives 2026-2027