Factory IoT Cost 2026: Budgeting a 12-Machine PoC, TCO and RFP
When estimating factory IoT cost, starting with “sensor price × number of machines” usually leaves network work, data integration, cybersecurity, training and support to surface later. This guide uses a fictional 12-machine PoC at a factory in Thailand to connect the initial budget, annual operating cost, three-year TCO, investment gate, PoC and RFP in one practical method. None of the figures is a market benchmark or a TOMAS TECH quotation. They are planning assumptions that readers must replace with their own downtime, labor, quality, energy and operating data.
Factory IoT cost pays for a sustained data product, not a box of sensors
The procurement unit is not a collection of sensors and gateways. It is a data product that acquires a plant signal, gives the data consistent meaning, delivers it to the right user, supports an action when a condition changes, and remains monitored and maintainable. Its cost should therefore be separated into at least seven layers:
- Source and interface: PLCs, existing instruments, added sensors, I/O, protocol conversion and OEM permission
- Edge: gateways, buffering, time synchronization, local processing, enclosures and power
- Network: industrial switches, Wi-Fi, VLANs, cabling, firewalls and communications
- Data model and integration: tag definitions, equipment hierarchy, units, quality flags, APIs and MES/ERP links
- Application: dashboards, alerts, approvals, reports and mobile views
- Security and acceptance: identity, access, encryption, updates, logs, backup and testing
- Lifecycle operation: monitoring, incident response, change, training, documentation, updates and retirement
A low-cost sensor does not make a low-cost project if the signal is undocumented and the equipment maker must be consulted repeatedly. Conversely, a more expensive device may reduce total engineering effort when a machine can expose approved, standardized tags and the equipment IDs and units are already governed. Before comparing unit prices, normalize what each quotation includes and what assumptions it makes.
Five decisions to fix before an IoT installation quotation
Put the following five decisions on one page before requesting a price. Asking vendors simply to “visualize 12 machines” invites each bidder to define a different scope, so their totals cannot be compared.
1. Whose production decision will change?
“Visualize utilization” is not yet an operational use case. Define the decision: a shift leader calls maintenance after a ten-minute stop; quality stops a process when defects rise under the same conditions; production control resequences today’s plan after a constraint changes. Once the decision is explicit, the refresh interval, alert latency, history, screen and access requirements can be derived.
2. Where is the boundary around the 12 machines?
State whether the boundary includes only the machines or also upstream and downstream equipment, inspection, and utilities. Twelve machines with two run/stop points each are fundamentally different from twelve machines exposing hundreds of temperature, pressure, product, lot and alarm tags. The equipment register should include manufacturer, model, age, PLC, available port, warranty restrictions, panel space and allowable shutdown time.
3. Who owns each definition?
Assign responsibility for approving and changing data definitions. IT may operate the server while production owns the authoritative stop-reason codes. Without an owner, a dashboard may run while the meaning behind its numbers changes month by month, eventually destroying trust.
4. What proves that the PoC passed?
“We saw the data” is too weak. Test whether data required for the target decision arrives within an agreed loss rate, latency and timestamp tolerance; whether it recovers after a link failure; and whether users can take the intended action.
5. What opens the scale-out gate?
Define before the 12-machine PoC what must be true to extend to one line or the whole factory. Machine variants, network capacity, licensing meters, operating headcount, support hours and shutdown windows can turn an inexpensive demonstration into an expensive redesign.

Illustrative 12-machine factory IoT PoC budget: THB 1,438,650 initially
The following is a fictional planning model for 12 machines at a factory in Thailand. It excludes VAT and is neither a market price, a standard range nor a TOMAS TECH quote. Treat it as a completeness worksheet, not an estimate produced after a site survey.
| Initial cost item | Assumption | Amount (THB, excluding VAT) |
|---|---|---|
| Edge gateways | 3 × 45,000 | 135,000 |
| Source interfaces/sensor packages | 12 × 18,000 | 216,000 |
| Industrial network changes | Lump sum | 120,000 |
| Data collection/integration engineering | Lump sum | 360,000 |
| Dashboard/alert workflow | Lump sum | 180,000 |
| Security design and acceptance testing | Lump sum | 150,000 |
| Training, manuals and handover | Lump sum | 90,000 |
| Subtotal | 1,251,000 | |
| Contingency | 15% of subtotal | 187,650 |
| Illustrative initial budget | 1,251,000 + 187,650 | 1,438,650 |
The arithmetic is 3 × 45,000 = 135,000, 12 × 18,000 = 216,000, a seven-item subtotal of 1,251,000, and contingency of 1,251,000 × 15% = 187,650, producing 1,438,650 THB. Fifteen percent is also only an assumption for this exercise, not a recommended universal rate. Where old machines, missing drawings, night work, OEM attendance or multilingual training create uncertainty, build a risk register and apply ranges to the affected items.
Why looking only at THB 351,000 of hardware is misleading
The THB 135,000 of gateways and THB 216,000 of source packages total THB 351,000—only about 24.4% of this illustrative initial budget. The rest is network, integration, application, security, handover and contingency. Buying the hardware first can leave the factory with equipment that cannot be safely connected, data whose meaning is inconsistent, or a system the local team cannot support.
The 24.4% ratio is specific to this model and must not be generalized to other plants. Its useful lesson is structural: an RFP needs separate lines for all the work, rather than a sensor-only comparison.
Why the example assumes three gateways
The model groups 12 machines into three sets, with one gateway serving four machines. Actual quantity depends on layout, control-network boundaries, failure domains, protocols, processing load and redundancy. Consolidating every machine on one gateway may lower hardware cost but lets one failure stop all acquisition. One gateway per machine narrows the failure domain but multiplies updates, certificates and spares.
What belongs in the THB 120,000 network-change assumption
It covers more than switches or access points: survey, port and bandwidth checks, VLAN, routing and firewall configuration, cabling, panel work, labeling, testing and configuration backup. For wireless, validate interference, roaming, client capacity and an alternative path during outage—not just signal strength. See our guide to industrial Wi-Fi design for a factory in Thailand for a deeper checklist.
Why THB 360,000 of integration engineering can vary sharply
Integration effort depends not only on tag count but also on the number of interpretation loops. A run bit may have reversed logic on one machine, a stop reason may be manual, the unit may change with product, and PLC clocks may drift. Request a tag list, transformation rules, equipment/line/product masters, retention rules and API responsibility boundaries as deliverables.
Annual OPEX of THB 630,000 and three-year TCO of THB 3,328,650
Approving only the initial budget can leave the next fiscal year without funding for cloud, communications, monitoring, backups and small changes. A technically working system then becomes operationally unsustainable. The fictional annual assumptions are:
| Annual operating item | Assumed annual amount (THB) |
|---|---|
| Cloud/platform/communications | 180,000 |
| Support and monitoring | 240,000 |
| Backup and security maintenance | 120,000 |
| Minor changes and data-model maintenance | 90,000 |
| Annual operating total | 630,000 |
The three-year TCO is 1,438,650 + 630,000 × 3 = 3,328,650 THB. This simple model assumes flat OPEX and omits tax, financing, major expansion, replacement and exchange-rate effects. A financial business case should follow the company’s policy for depreciation, discount rate, tax and residual value.
Cloud cost is not one price meter
AWS IoT Core’s official pricing page, for example, separates meters such as connectivity, messaging, registry or Device Shadow operations, and rules or actions depending on architecture. This is not an endorsement of a particular cloud. It illustrates why “devices × monthly fee” is incomplete. State message frequency, payload, retention, analytics, external transfer and region, then rerun the appropriate calculator immediately before procurement.
Streaming every tag once per second creates a different communications and processing profile from sending only state changes. Yet reducing transmissions without reference to the use case can hide short stops or process precursors. Derive sampling from the production decision first, and then consider edge aggregation and compression.
Support is more than calling someone after a failure
Routine operation watches endpoint health, missing data, latency, clock drift, free storage, certificate expiry, failed updates and backup status. Machine modifications, new products, PLC changes and personnel changes also require tag, role and documentation updates. If this work is absent from OPEX, the dashboard can diverge from plant reality within months.
Eight variables that drive factory IoT cost
The variables below usually explain more of the quotation spread than machine count alone.
1. Connectivity of existing equipment
Engineering depends on whether an available port exists, whether the PLC program may be changed, and whether a modification affects the OEM warranty. Collecting minimum state information from a signal tower is one option where invasive changes should be avoided. Our signal-tower data collection guide for Thailand factories explains how to frame that option.
2. Tag volume and semantic complexity
Equal tag counts do not imply equal effort. Simple running states differ from data joining lot, recipe, product and quality. The transformation rules between “signals available” and “information required for a decision” are part of the budget.
3. Refresh and latency requirements
Minute-level data may be enough for a daily report, while rapid response to micro-stops may require seconds. Avoid demanding the fastest rate for everything. Set service levels by use case.
4. Availability and offline operation
Edge design changes with the required offline buffer period, resend order and duplicate handling. Control must continue if the cloud is unavailable. IoT monitoring and analytics should not casually become a dependency of safety control or machine interlocks.
5. Depth of cybersecurity controls
Cost changes with expectations for per-device identity, least privilege, keys, segmentation, signed updates, vulnerability response and log retention. NIST IR 8259 Rev. 1, *Foundational Cybersecurity Activities for IoT Product Manufacturers*, finalized in April 2026, sets out foundational cybersecurity activities that IoT product manufacturers should consider before sale. It can inform procurement requirements for the capabilities and information customers need to reduce risk. Separately, a factory should budget for monitoring, updates and retirement across the deployed system’s lifecycle.
6. Integration with existing systems
A stand-alone dashboard is different from integration with MES, ERP, CMMS, quality systems or BI. APIs, master synchronization, error handling and responsibility boundaries expand. For the operational side, see our guide to a production progress monitor for factories.
7. Languages and user enablement
Thai, English and Japanese screens, alerts and procedures require more than literal translation. Plant equipment names, stop reasons and escalation phrases must be governed so all shifts make the same decision. Training cost includes shift coverage, comprehension checks and maintaining new-hire material.
8. Reusability for scale-out
A custom first-machine build can look fast but repeat the same effort on machine 13. Separate reusable connection templates, tag dictionaries, equipment models, screens, tests and operating procedures from machine-specific elements.
How OPC UA and MQTT affect cost design
The OPC Foundation positions OPC UA as a secure, vendor-independent interoperability foundation for factory automation. Standard expression of equipment structures and meaning can reduce custom mappings as consumers multiply. However, an OPC UA-capable machine is not automatically an integrated machine. The project must still govern exposed tags, namespace, units, permissions, certificates and update responsibility.
MQTT is an OASIS lightweight publish/subscribe protocol with characteristics useful for constrained devices and unreliable networks. MQTT by itself does not solve semantics, access policy, device management or end-to-end security. Topic design, QoS, retained messages, retries, authentication, authorization and certificate renewal remain design decisions.
Do not make the RFP a binary “OPC UA or MQTT” contest. OPC UA may acquire structured machine data, MQTT may deliver events upward, and APIs may serve enterprise integration. Standards earn their keep by reducing rework when equipment or vendors change, but only when interface specifications and acceptance tests are documented.

A two-stage acceptance model that protects the PoC budget
Separate PoC acceptance from production acceptance. A PoC tests not only whether a signal is technically accessible but also whether the operational hypothesis works. Production acceptance adds long-run stability, support, recovery and cybersecurity.
Checks for PoC acceptance
| Dimension | Example form of an acceptance condition |
|---|---|
| Decision | The shift leader can follow the defined response after the target alert |
| Completeness | Measure missing data for target tags and period; remain within an agreed threshold |
| Latency | Measure event-to-display/alert time; remain within a use-case threshold |
| Time | Measure and record clock difference across PLC, gateway and server |
| Offline | Simulate the agreed outage; verify local buffering and resend |
| Meaning | Equipment ID, unit, state and quality flag match the approved dictionary |
| Adoption | Users on target shifts operate the screen and leave a decision record |
This article deliberately supplies no universal numeric threshold; each use case is different. The RFP should define the measurement method, period, owner, evidence and retest rule.
Additional checks for production acceptance
- Recovery and data consistency after power, network and server failures
- Handling of full buffers, clock drift, duplicates and out-of-order data
- Role-based access, leaver disablement and service-account governance
- Signed updates, rollback and end-of-support notification
- Restoration from backup, including recovery time and recovery point
- Monitoring recipients, first response, escalation and records
- Handover and ownership of configuration, source, tag dictionary and credentials
- Data return, deletion, configuration migration and equipment removal at contract exit
The NIST IoT Device Cybersecurity Capabilities Catalog is a useful reference for device identification, configuration, data protection, logical access to interfaces, software update, cybersecurity state awareness and support documentation. Do not maximize every control blindly; select requirements based on factory risk and use, and convert them into acceptance tests.
Twelve items for a factory IoT RFP
A comparable quotation requires contract language for assumptions, deliverables, acceptance and operations—not just a feature list.
- Purpose and target decision: who changes which decision, not only which KPI should improve
- Plant scope: the 12-machine register, layout, controls and shutdown windows
- Data scope: candidate tags, units, cadence, quality, history and system of record
- Non-functional requirements: latency, availability, offline duration, retention and concurrent users
- Network boundary: OT/IT flows, ports, VLANs, remote support and responsibility
- Cybersecurity: device identity, authentication, least privilege, encryption, logging, updates and vulnerability response
- Data model: hierarchy, naming, units, timezone, quality flags and change procedure
- Screens and workflow: recipients, acknowledgment, approval, escalation and audit history
- Tests and evidence: PoC and production methods, pass/fail rules and retesting
- Training and documentation: language, roles, shifts, administrator training, source and configuration handover
- Support and SLA: monitoring hours, intake, priority, response, restoration target and exclusions
- Price and exit: CAPEX, OPEX, unit rates, expansion, data return and migration support
Make the response sheet mirror this structure. Provide columns for included, excluded, assumption, quantity, unit price, lump sum, third-party charge and validity. If bidder A includes network work and bidder B excludes it, normalize scope rather than rank the raw totals.
Separate initial, recurring and scale-out price tables
Ask for unit rates that allow the next deployment wave to be forecast:
- One additional machine: interface, configuration, tag onboarding and test
- One additional gateway: device, build, certificate and monitoring registration
- One additional 100-tag block: mapping, history, screen and test
- One additional line: network, master data, screen and training
- Additional user, site or storage: license and operational impact
- In-hours and out-of-hours engineering support, including minimum charge and travel
- Annual renewal: software, certificates, vulnerability response and restore test
- Contract exit: data export, documents, configuration, deletion evidence and migration
Excluding reusable foundations can make the pilot look cheap and scale-out expensive. Conversely, forcing an uncertain full-plant rollout into a fixed price makes the vendor price a large risk premium. A practical PoC agrees design principles and unit rates, then confirms each deployment wave after a machine survey.
The value gate: adjust benefits for evidence confidence and adoption
Factory IoT case studies often highlight large improvement percentages, but another plant’s result cannot simply be pasted into your business case. The fictional sensitivity below deliberately discounts benefit. It is neither a guarantee nor a recorded customer result.
- Modeled gross annual benefit:
1,920,000 THB - Evidence confidence:
70% - User-adoption realization:
80% - Risk-adjusted realized benefit:
1,920,000 × 0.70 × 0.80 = 1,075,200 THB/year - Net annual benefit after OPEX:
1,075,200 - 630,000 = 445,200 THB/year - Simple initial-investment payback:
1,438,650 ÷ 445,200 ≈ 3.23 years
The model is intentionally conservative. Whether 3.23 years is acceptable depends on the company’s hurdle, asset life, risk and strategic purpose. Replace the THB 1,920,000 gross benefit with evidence from your own operation.
Downtime
Use contribution loss per minute, recovery labor, work-in-process disposal and downstream effects. “Machine capacity × sales price” can overstate value, so check the constraint and whether production can actually be recovered. Break the hypothesis into the number of short stops detected, the portion actionable and minutes saved.
Labor
Measure paper-report consolidation, rounds, rekeying and meeting-pack preparation. Time released is not automatically cash saved. State whether value appears as reduced overtime, vacancy absorption or reassignment to improvement.
Quality
Include scrap, rework, sorting, customer loss and expedited freight. Data alone does not reduce defects. Benefit requires a workflow that detects a condition, authorizes a stop and corrects the cause.
Energy
Join machine-level electricity, compressed air or steam to production volume and operating state. Understand the difference between monitoring accuracy and billing meters, then compare before and after under matched conditions.
For each benefit, record evidence source, period, sample, owner and adoption. At the PoC gate, replace assumptions with measurements. Scale if the evidence passes; redesign or stop if it does not. This avoids expansion merely because hardware has already been purchased.

Procurement and operating questions for a Thailand factory
Reflect the plant’s languages, maintenance footprint, imported devices, network ownership, power and communications conditions in the RFP. These are site-survey questions, not assumptions to answer from a generic template.
Do not book BOI incentives before eligibility is confirmed
Thailand BOI’s Investment Promotion Guide 2025 describes digital and other activities that may be eligible for promotion. Eligibility depends on the activity, entity, investment and application, and must be confirmed case by case. This fictional model includes no incentive. If a possibility exists, confirm it with BOI or an appropriate adviser and do not treat an unapproved tax effect as guaranteed benefit.
Choose parts and skills that can be maintained locally
Check whether replacement gateways, power supplies and converters can be obtained in Thailand and their lead times. A design configurable only by an overseas specialist extends outages. During acceptance, ask the local team to demonstrate log review, swap, restore and first-line diagnosis.
Put timezone and shifts in the data model
Even if storage is normalized to UTC, displays and reports must handle Asia/Bangkok dates, shifts crossing midnight, breaks and planned stops. Define the time source and monitoring for PLCs, gateways and servers. Clock error can create a false relationship between a stop and a defective lot.
Common cost-cutting ideas and their side effects
Install a free dashboard first
Saving a license does not remove authentication, backup, patching, vulnerability response or data-model maintenance. Judge operating ownership, not tool price. Open source is not inherently unsuitable; it requires an explicit internal support capability.
Connect every machine at once
Volume buying can help unit prices, but a wrong assumption is then multiplied across the plant. Use representative equipment and users to stabilize the connection template and acceptance tests before waves of rollout.
Send every data point to the cloud
Future reuse is possible, but communications, storage, confidentiality and discoverability suffer. Separate raw data, aggregates, events and audit logs by purpose and retention. Without disposal rules, the factory pays indefinitely for unused data.
Add cybersecurity immediately before go-live
Retrofitting device identity, certificates, access and segmentation can force connection and hardware redesign. Apply production principles on a small PoC scope and test whether the operation can scale.
Finish training with one handover presentation
Knowledge disappears as attendees move roles. Build role-based procedures, recordings, exercises, comprehension checks, new-hire learning and a document owner. Training should cover whom to contact when the data looks wrong, not just where to click.
Checklist for evaluating factory IoT case studies
An improvement percentage alone does not establish comparability. Ask:
- Equipment age, manufacturers, controls and machine count
- Tags, cadence, retention and treatment of missing data
- Existing network and system condition
- PoC period and measurement period after production launch
- Baseline and influence of other improvement programs
- Users, decisions and changes to standard work
- Whether annual OPEX is included as well as initial cost
- Boundary between vendor work and customer effort
- Treatment of tax, incentives, licenses, communications and support
- What was reused at scale and what remained custom
Published cases show possibility; your survey and measurement build the budget. Ask a vendor to explain both similarities and differences and how each difference affects cost and benefit.
A 90-day path from budget to production decision
Days 1–15: fix the purpose and site conditions
Create the target-decision statement, owner, 12-machine register, network view, candidate tag list and shutdown windows. Use short manual measurement to establish current downtime, rounds, rekeying and quality-response effort. Include production, maintenance, quality, planning, IT, security, procurement and finance.
Days 16–30: build the RFP and value hypothesis
Write PoC and production acceptance, price structure, responsibility boundaries and deliverables. Separate benefit into downtime, labor, quality and energy, then apply evidence confidence and adoption. Hold one bidder briefing and share the same answers with all bidders.
Days 31–45: compare proposals and inspect hardware
Compare exclusions, assumptions, risk, OPEX and scale-out rates—not only total price. Validate candidate gateways and connections on representative hardware, and document OEM warranty constraints. Security reviews remote support, accounts, updates and logs.
Days 46–75: execute the PoC
Test acquisition, offline buffering, time, screens, alerts and the user decision. Review missing-data rate, latency, usage, response records and modeled benefit weekly. Relate feature requests to the purpose and record any scope change.
Days 76–90: accept and decide the rollout
Record pass/fail and open risk, replace the original assumptions with measurements, and recalculate three-year TCO and risk-adjusted benefit. If proceeding, set equipment-type templates, deployment waves, shutdown windows, training, support and budget. If stopping, preserve the equipment facts and failure causes as an asset for the next investment decision.
FAQ: factory IoT cost and deployment
How much does factory IoT cost to start?
There is no dependable universal entry price because equipment, tags, network, integration and acceptance differ. THB 1,438,650 in this article is a fictional 12-machine model, not an average or quotation. Start with one production decision and representative machines, then separate CAPEX, OPEX, contingency and scale-out rates after a survey.
How many machines should an IoT PoC cover?
Representativeness matters more than count. Include old and new equipment, different PLCs, a difficult communications location and users on major shifts. One easy machine proves little about expansion, while every machine creates avoidable rework. Select the smallest scope that can test the acceptance conditions.
What is the most important part of a factory IoT RFP?
The target decision, equipment/data boundary, separate PoC and production acceptance, operating responsibility and price table. If they are unclear, bidders price different scopes. Write who decides what, when, and what evidence constitutes a pass before listing features.
Is cloud or on-premises cheaper for factory IoT?
Neither is universally cheaper. Cloud has usage meters, connectivity, storage, transfer and operations; on-premises has servers, redundancy, power, updates, backup and internal labor. Compare three to five years with equivalent availability, security and operating boundaries.
Do OPC UA and MQTT always reduce integration cost?
No. Standards support reuse and interoperability, but existing machine support, tag design, semantics, access, certificates and testing remain. Specify the information model, quality, time, errors and maintenance responsibility, not only a protocol name.
Can a published IoT case-study saving be used in our investment plan?
Use it as context, not as your forecast. Equipment, baseline, behavior, period, other programs and cost boundary differ. Build gross benefit from your own data, discount for evidence and adoption, subtract annual OPEX and replace assumptions during the PoC.
Is factory IoT cybersecurity an initial or operating cost?
Both. Initial scope includes identity, segmentation, permissions, encryption, logging and acceptance. Recurring work includes monitoring, certificate renewal, patches, vulnerability response, restore tests, account review and retirement. Plan from design through disposal.
How should the cost of expanding from 12 machines to 100 be estimated?
Do not multiply the 12-machine total. Separate shared design, per-machine onboarding, gateway capacity, network expansion, license tiers, site work, training and support staffing. Measure effort by equipment type in the PoC, then update the reusable and custom portions.
Conclusion: work backward from acceptance and operations
The right starting point for factory IoT cost is not a sensor catalogue; it is the production decision to improve. From that decision, define the equipment and data boundary, then price source, edge, network, model, application, security and operations. In this fictional example, the initial budget is THB 1,438,650, annual OPEX is THB 630,000, and three-year TCO is THB 3,328,650. A risk-adjusted net benefit of THB 445,200 per year produces a simple payback of about 3.23 years, but every input is an assumption requiring replacement with plant evidence.
Do not let the PoC finish at “the dashboard works.” Test missing data, latency, offline buffering, timestamps, access, updates, backup and vendor exit. Put the same cost structure and acceptance language in the RFP to make quotations comparable and reduce redesign after hardware purchase.
TOMAS TECH can discuss a Thailand factory IoT project while it is still at the budgeting, 12-machine PoC scoping or RFP-design stage. If you want to separate initial, recurring and scale-out cost using your existing equipment and operating constraints, contact us through the TOMAS TECH inquiry page.
References
- NIST IR 8259 Rev. 1, *Foundational Cybersecurity Activities for IoT Product Manufacturers*, Final, April 2026
- NIST, *IoT Device Cybersecurity Capabilities Catalog*
- OPC Foundation, *OPC UA for Factory Automation*
- MQTT.org, *MQTT: The Standard for IoT Messaging*
- AWS, *AWS IoT Core Pricing*
- Thailand Board of Investment, *Investment Promotion Guide 2025*