IoT Hub vs Event Hubs — Why Most Manufacturers Pick the Wrong Service

0:00 Here's a problem I keep seeing in manufacturing. A team sends plant telemetry into Azure through which ever service sounded right in the first workshop, then discovers six months later that the data path can't support how the plant actually runs. IoT Hub and event hubs can both receive events. That's where the confusion starts. But one deals with a known device and its life in the system while the other moves large streams of data for many readers. So let's separate device control from stream processing, then put them back together in a factory architecture that actually scales. We'll start with the shop floor symptom, not an Azure product page. The plant that cannot explain its own data path, picture a normal plant, not a greenfield demo site with three sensors on a bench.

0:40 You've got PLCs from different eras and edge gateway near each line and MES tracking production, and ERP holding work orders and material data, a historian that operators already trust, and Power BI reports pulling numbers into meetings. Somewhere beyond that there's Azure, usually there's also a data lake, a stream processor, perhaps Microsoft fabric, and a few cloud apps built for maintenance or quality. Each part may work on its own. The trouble starts when someone asks how a single machine signal traveled from the line into a report. Take a temperature tag from an oven online for. The PLC exposes it, a gateway reads it, maybe the historian records it locally. The gateway also sends it to Azure, then one dashboard shows a five minute average, another report shows a maximum value, and a third system flags an alarm from a different copy of the same signal.

1:22 Nobody is lying, that's worse. Each team can point to data, but they can't point to one agreed path, one agreed meaning, and one clear owner. The maintenance engineer sees a temperature trend and asks whether the sensor still works. The data team asks which cloud endpoint received the event, operations asks which value controls the quality decision, by then the meeting has stopped being about the oven. It's about trust. This gets especially awkward when the plant has connected equipment through a mix of direct devices and edge gateways. A gateway may represent an entire line. It may collect data from 20 PLCs, normalize some tags, discard others, and forward a subset to the cloud. That can be a sensible design, but only if someone can explain what identity that gateway uses, what equipment sits behind it, and what happens when the gateway itself looks suspect.

2:06 Operations tends to ask a practical question, who owns this machine connection? It asks a different equally fair question, who owns the credential? Those questions should lead to the same answer. In a lot of plants, they don't. The OT team knows the physical asset, its location, and the technician who can replace it. The cloud team knows a connection string exists in a config file, though they may not know whether it belongs to a line gateway or test unit or somebody's temporary integration from last year. That setup works right up until it doesn't. Imagine a gateway begins sending bad data, or its credentials may have leaked. The security team wants to shut off that one source while they investigate. The plant wants the rest of the line online. Yet, the only option may be to rotate a shared access key used by several gateways, which cuts off more than the one device under review.

2:49 Now you've turned an identity issue into a production issue. You can also see this problem in dashboards. A report can look clean, refresh on time, and still sit on top of a weak architecture. The visual tells you data arrived. It doesn't tell you whether the source remains authorized, whether a device can receive a configuration change, or whether another consumer can replay the same telemetry after its logic changes. A dashboard is the last few feet of a long pipeline. It can't fix the pipe. So before we compare Azure services, name the mistake clearly. Teams treat all incoming machine data as the same kind of traffic. They see an event choose a hub with event in the name and move on. But a machine reading, a device identity, and a stream for analytics are related. They are not the same job. The wrong question.

3:31 Which hub should we use? Once the conversation reaches Azure, someone usually asks, which hub should we use? It sounds sensible, but it starts the architecture review in the wrong place. To start with the traffic, not the service name, a plant doesn't send one kind of data to the cloud. It sends different kinds of information that behave differently, carry different risk, and need different handling after they arrive. If you treat all of it as generic telemetry, you'll select a service based on a feature list, then spend the next year filling gaps with custom code. Think about the source first. Is this a managed field device that needs a known identity, a controlled connection, and a way to receive configuration? Is it a trusted line gateway that already sits inside your OT boundary and sends a dense normalized feed? Or is it both where the gateway needs management, but its data needs broad stream processing?

4:14 Those lead to different designs. Take a gateway next to a packaging line. It reads OPC UA data from several machines, applies a local data contract, and publishes cycle counts, alarms, energy readings, and quality signals. If you need to know which gateway connected, disable that specific gateway during an incident, or change its reporting settings while it sits offline, you have a device management need. That doesn't disappear because the gateway also sends a lot of data. Now take a central data service inside your cloud platform. It receives normalized production events from several trusted site integrations and sends them into analytics. Nobody needs to update its firmware. Nobody needs a cloud side record of its desired configuration. The concern is throughput, parallel readers, retention and recovery after consumer fails.

4:54 That is a stream problem. You can see why the word hub causes trouble. Both services accept incoming data. Both can sit in a real time architecture. Both can connect to downstream processing, but shared ingress doesn't mean shared responsibility anymore than a machine network switch and a production database solve the same problem because data passes through both. The service name is in implementation detail. The message pattern comes first. So when I review a manufacturing architecture, I ask the team to separate the flows before anybody opens the Azure portal, put telemetry in one column, put commands in another, put configuration state in the third, then put business workflow messages somewhere else because they often need a very different delivery and ownership model. Telemetry describes something that happened, a cycle completed, a vibration reading crossed a limit, a motor drew a certain amount of current at a point in time.

5:38 Telemetry may arrive often and several systems may need to read the same stream for separate reasons. Command's work in the other direction, a cloud application requests an action from a device or gateway and expect some form of response. In a factory, that request should never jump around the plant safety model or take authority away from the PLC. Still, a request to refresh a gateway connection, collect diagnostics or begin a controlled software task belongs to a different path from a temperature sample. Configuration state is different again. Suppose a gateway should report an approved software version, use a defined sampling rule or apply a named recipe mapping. The cloud may request that state while the gateway reports what it actually runs. That exchange needs to survive a temporary loss of connectivity. It isn't a continuous event stream and it isn't an immediate command.

6:21 Business workflow has its own rules, a quality hold, a maintenance work request or a production confirmation isn't just another sensor event. Somebody owns the work, a system must track whether the work completed, failed or needs attention. Sending raw tag changes straight into ERP because everything is event driven is one of those ideas that sounds modern until a duplicate message creates a real operational mess. So map the source, the type of information, the direction of travel and the required outcome. Ask who owns the producer. Ask who can cut off that producer if something goes wrong. Ask whether the cloud must communicate back. Ask how many independent systems need to consume the data and whether they need to process it again later with corrected logic. Only after those answers should you select as your services. This doesn't make the decision slower.

7:01 It removes a lot of fake simplicity early, which is cheaper than rebuilding identity, replay or control parts after the plan depends on them and it gives everyone the same language for the next step. What exactly counts as an event on a production floor? Events, messages, state and commands. Before you choose a service, give each piece of traffic its real name. That sounds almost too basic, but this is where architectures start to drift. A stream of numbers can look like a stream of numbers right up until somebody tries to use it for the wrong job. An event is a fact tied to a point in time. The press completed a cycle at 10.03.14, a motor vibration reading reached a given value, a barcode scanner read a pallet ID, an oven temperature across the limit. Once an event happened, you don't edit it to match your current view of the plant.

7:44 You record it, attach context and let downstream systems decide what it means. Events answer a simple question, what happened and when. That wording matters because an event isn't necessarily a request for action. A vibration reading may later drive a maintenance rule, but the reading itself only reports what the sensor observed. If you blur that line, raw measurements begin to act like business decisions and people start building alarms, work orders and controls on data with no clear contract. Picture a packaging machine sending its cycle count every few seconds. Each count is an event. The count might feed an OE calculation, a live lineboard and a data store for later analysis. Those consumers can each interpret the event for their own purpose, but none of them should quietly rewrite what the machine reported.

8:25 A command works the other way. It tells a device or gateway to do something. Maybe the cloud requests a diagnostic package. Maybe it asks a gateway to restart a data collector during a plant support window. Maybe it asks the gateway to test whether a connection to an OPC UA server still responds. A command has intent behind it and the sender expects a device side action, a response or at least a clear record that the device received the request. Commands carry responsibility. If a command fails, somebody needs to know whether the device never received it, rejected it, timed out or completed it with an error. That makes a command very different from a sensor event that arrived late or didn't arrive at all. You can tolerate different failure behavior because the two flows mean different things.

9:06 And in manufacturing, there is a hard boundary around this. A cloud command doesn't become machine control just because it reaches an edge gateway. The PLC safety system and local control logic remain in charge of any action that can affect people, equipment or product. The cloud may request a controlled task, but the edge layer must enforce what that request can and cannot do. Then there is state. State describes the current known condition of something rather than the history of everything that happened to it. Think about a gateway that runs software version 4.2, reports every 30 seconds and currently uses the approved mapping for line 2. Those are state values if you ask, what does this gateway run right now in the event? You want the latest known answer, not 10,000 past updates. State changes over time, but you don't need every old version to understand the current one.

9:48 That makes state useful for settings, health, version data and operational facts that must stay known even when the device disconnects. A device can report what it currently sees, the cloud can request a target setting. When the device reconnects, it can compare the requested state with its local state and act through its own rules. Now consider a business message. This is where many factory programs create trouble because business work often enters the same pipeline as telemetry. A business message tells a system that work must happen and must be tracked. Create a maintenance request, put this lot on quality hold, confirm that the production order reached a certain step. These aren't passive facts for any reader to inspect when convenient. They create an obligation and owner and a status. Someone must process that work.

10:29 Suppose a quality rule detects repeated out of range readings from an oven. The readings remain events. A later instruction to open a quality review becomes business work. The MES, quality system or maintenance platform needs a defined process for it, including retries, duplicate handling, ownership and proof of completion. Treating that work like a raw telemetry stream invites confusion when a consumer re-starts and sees the same data again. So use the words carefully. Events tell you what happened. Commands request in action. State records what is currently known. Business messages create work that somebody must complete. Both IoT Hub and the event hubs can receive events. They just begin from very different assumptions about what needs to happen before and after that event enters the cloud. The first mental model, identity gate versus data highway.

11:12 Use this mental model before you compare any Azure feature. IoT Hub is the controlled gate for connected equipment. Event hubs is the data highway after the gate. A controlled gate doesn't just let traffic through. It checks who is asking to enter, whether that source belongs there and whether access should continue. In an industrial setting, that source might be a sensor, an edge computer or a gateway collecting data from a group of PLCs. IoT Hub treats that connection as a device relationship, not just a payload arriving at an endpoint, that distinction changes the design. When a gateway connects through IoT Hub, the cloud can treat it as a known participant in the system. The gateway has an identity it can authenticate. Its access can be managed separately from another gateway on another line. The cloud can maintain a relationship with that device over time, instead of only seeing a sequence of anonymous messages.

11:57 Think about a plant with 10 packaging lines. Each line has an edge gateway, and each gateway sends production data upstream. If one gateway begins behaving in a way you don't trust, you don't want to shut down the entire telemetry path for the plant, you want to deal with that one connection. That is the gate problem. Event hubs starts from a different question. It doesn't ask, "What is the life cycle of this field device?" It asks, "How do I take a lot of incoming events, keep them moving and let several systems read them without blocking each other?" That is the highway problem. A highway doesn't care whether a vehicle carries temperature readings, application logs, power data or normalized production events. It needs lanes, entry capacity, and a way for traffic to keep flowing when many producers send at once. Event hubs works the same way.

12:38 Producers write events into a stream and downstream consumers read that stream on their own schedule. One consumer might calculate OEE near real time. Another might send selected events into a lake house. A third might look for patterns in condition data. They all need the same operational facts, but they don't need to run as one application or wait for each other. The stream gives them that separation. Now take one sensor reading, say a vibration value from a motor. That reading can pass through both services in one architecture, but each service handles a different concern. At the IoT hub boundary, the question is whether the gateway or device sending the reading has permission to connect. In the stream layer, the question becomes whether several consumers can process the reading at scale, recover after a failure, and inspect recent history without slowing down the producer.

13:20 Same reading, different job. This is where teams often force a false choice. They ask whether the vibration reading belongs in IoT hub or event hubs as if the data can only live in one place. That question misses the path the data takes. If the source needs a managed cloud identity, a controlled relationship, and a way to receive cloud-side interaction, IoT hub belongs at the connection boundary. If the telemetry then needs broad distribution to analytics, reporting, storage, and stream processes, event hubs belongs in the streaming layer. You may need both, and that isn't duplication, it is separation of responsibility. One part of the system manages trust at the edge of the cloud. The other part moves operational data through the wider platform, trying to make one service handle both jobs can work in a small proof of concept mostly because nobody has yet asked difficult questions about scale, incident response, or a second consumer.

14:07 Production systems eventually ask those questions. There is also a useful warning in this model, a high-capacity data highway, does not become a device management platform because you attach a device ID inside every message. You can write an asset name into a payload, but that doesn't prove who connected. It doesn't give you a cloud-side relationship with the source. It only gives your downstream code another field to inspect. Likewise, a controlled device gate doesn't automatically become the right place for every stream in the enterprise. Back-end services, application logs, and large normalized feeds may need streaming capacity without any device relationship behind them. Calling all of it IoT traffic just because it came from a factory is how one endpoint turns into a bucket with no clear owner. Keep the boundary plain.

14:47 IoT hub owns the relationship with the device. The event hub owns the movement of the event stream. Once you see that split, IoT hub makes more sense from the device side. IoT hub starts with a device, not a payload. IoT hub begins with a question that event hubs doesn't try to answer, which device is connecting right now? Before a field device or managed gateway can connect, it has an entry in the IoT hub identity registry. That entry gives the source a device ID. It also holds the authentication setup and a status that controls whether that source can connect at all. The payload comes after that relationship exists. Think about a line gateway named line 4, gateway 0, 2. That cloud device ID doesn't need to match every label on the physical box, the Windows host name, or the asset number in your CMS.

15:29 Those identifiers may all exist, and they should link through your data model. But the IoT hub device ID has one specific job. It identifies the connection that Azure accepts and manages. Keep that job clear. A gateway might represent one physical device. It might also represent a cell with several PLCs, drives, and sensors behind it. IoT hub doesn't magically learn every asset below that gateway just because it receives telemetry. You still need a proper asset model that explains which source produced, which signal where it sits, and who owns it. What IoT hub gives you is a managed identity at the connection point. That becomes useful very quickly in a real plant. You can create an identity for each edge gateway, configure how it authenticates, and keep each connection separate from the rest of the fleet.

16:11 A new gateway joining a packaging line doesn't need access through the same shared secret as every other gateway in the site. Each connection has its own record. The registry also keeps an enabled or disabled status for that device identity. On paper, that sounds like a small control. In an incident, it changes the conversation. Say your monitoring picks up a gateway that suddenly begins sending malformed messages or the team suspects that it's credential appeared in the wrong place. You don't want the response to be, let's rotate the site-wide secret and see who breaks. That approach may protect the cloud endpoint, but it creates a second problem for the plant because unrelated gateways lose their connection, too. With a device-centric model, you can disable one identity under review. The rest of the fleet can continue sending data while you inspect the device, replace its credential, or take the gateway out of service.

16:54 Operations gets a narrower impact, security gets a clear action, and the architecture doesn't depend on someone remembering which machines share the string stored in an old deployment script. That level of control matters more as the fleet grows. A pilot often begins with one gateway and one developer-owned connection string. Nobody worries much because everyone knows where the hardware sits. Then the pilot becomes four lines, two plants, several support teams, and a mix of vendor equipment. The original shared connection setup stays around because it still works. Until an incident proves it doesn't, IoT Hub treats the field connection as something with a life in the system. It can be registered, authenticated, enabled, disabled, and managed as a distinct participant. That's a better match for industrial equipment than treating every incoming message as proof that the sender belongs there. Because a message can contain any device name you want, the connection needs to prove it.

17:37 There is a practical boundary here as well. You don't need an IoT Hub identity for every tag in a PLC or every value inside a gateway payload. Creating thousands of cloud identities for things that never connect independently just gives you another registry to maintain. Model the identity at the level where connectivity and accountability live. For some sites, that means one identity per managed edge gateway. For other cases, a direct cloud-connected device may need its own identity because it connects, authenticated, and receives cloud interaction on its own. The architecture should follow the actual trust boundary, not a diagram that looks tidy. This also changes fleet operations. When you can name the exact source that connected, you can build a cleaner process around onboarding, support, replacement, and incident response.

18:19 The cloud team knows which identity to inspect, the OT team knows which physical gateway that identity maps to. Neither side needs to guess from a stream of messages with a line name buried in Jason. That shared view helps connect the dots between IT and OT. IoT Hub doesn't remove the work of keeping asset records current. It gives that work a concrete connection point. If the plant can't map a cloud device identity back to a physical asset, a location, and an owner, the registry becomes just another list. But when those links exist, you can manage a fleet without treating every source as anonymous traffic. And once you start with identity, the security discussion becomes much more specific. A per-device security in an industrial network. Once every connection has an identity, you can give it its own security boundary. That changes how you handle a plant incident because you're no longer trying to infer the source from a tag inside a payload after the data already entered your cloud environment.

19:07 IoT Hub supports device authentication through SS tokens based on symmetric keys or through X, 509 certificates over TLS. Both approaches can work, but they place different demands on the device, the gateway software, and the team responsible for operating the fleet. With a symmetric key, the device holds a secret. It uses that secret to create a time-limited SS token. And IoT Hub checks the token when the device connects or performs an operation. This can suit constrained hardware and gateways where certificate handling would add more operational work than the use case justifies. But be clear about what you are protecting. If someone extracts that symmetric key from a field device, they can create new SAS tokens until you disable the device identity or rotate the key. A short token life limits how long a stolen token works.

19:49 It doesn't protect the underlying key. The secrets still need safe storage, ideally in hardware designed to protect it, not in a plain text-config file on an edge PC that several people can log into. That distinction tends to get lost in security diagrams. A say as token expiring every few hours sounds reassuring, but a copied device key can keep producing fresh tokens. You still need a process that can identify the affected device, disable its access, replace the credential, and confirm that the replacement is the intended physical asset. Security is not the token format. Security includes what your team can do at 2 in the morning when a gateway starts acting strangely. X509 certificates give you a different model. The device proves its identity through a certificate during the TLS connection and certificate chains can link the device back to a trusted certificate authority.

20:33 For larger fleets and higher risk environments, that often gives you a cleaner path for device identity and certificate rotation. It also creates work. You need a plan for issuing certificates, protecting private keys, tracking expiry, rotating certificates before they expire, and recovering a device that misses its rotation window. Certificates don't remove fleet management. They force you to take fleet management seriously, which is usually the point. IoT Hub lets you scope the credential to one device identity. That scope matters. A gateway online fork can authenticate as line 4 gateway 02 while a gateway in another building uses its own credentials. If the first gateway becomes suspect, you can disable that identity in the registry and stop that one connection. You don't need to pull the plug on the whole plant data path.

21:13 Think of an incident where an edge PC has been exposed during vendor support. You may not yet know whether anyone accessed the device credential. With per device access, you can quarantine the gateway. While the OT team checks the machine side impact and IT reviews the system. Other lines keep their data connection. The response stays narrow because the credential scope stayed narrow. That is much harder when many producers share one event hubs access key. Event hubs can protect a stream through shared access policies or Microsoft EntraID permissions, which works well for trusted applications and manage cloud services. But if many field sources rely on the same shared producer secret, rotating that secret affects all of them. You then have a coordination problem across every gateway that uses it.

21:54 And those are rarely updated at the same pace. A shared secret is simple until it becomes shared responsibility. IoT hubs device registry gives you allow and block control at the connection level. You can enroll the identities you expect. You can disable the one you don't trust. You can rotate its credentials without touching every other source. This doesn't guarantee that the data behind a valid gateway is correct. And it doesn't replace network segmentation, endpoint protection, or OT security controls. It gives you a clean cloud side control point. Transport security matters too. TLS protects data while it moves between the device and Azure. And newer TLS 1.3 support improves the protocol baseline. That is a good change. It is not a magic shield around an old gateway with weak local access controls, unpatched software, or a private key copied into three backup folders.

22:36 The same caution applies to newer certificate management options and Azure device registry direction. Better tooling can reduce manual certificate work and help teams operate a larger fleet with more consistency. Treat preview capabilities as something to assess carefully before you place production dependence on them. The architecture still needs named ownership, documented replacement steps, and a way to trace the cloud identity back to equipment on the floor. Security only becomes useful when it survives normal operations. Devices fail, gateways get replaced, certificates expire, and people change roles. The next question is whether your device model can live through all of that without turning every routine change into a plant-wide outage. Device lifecycle, enrollment, change, disable, replace.

23:17 A device identity only helps if it fits the way equipment changes on a real production line. New gateways arrive, edge PCs fail. A vendor replaces a unit during a weekend shutdown. Some equipment gets retired while its old cloud connection keeps trying to talk because nobody removed it from the integration plan. That is normal plant life. Take a new gateway joining line four. Before it sends any production data, somebody should know what it represents, who owns it, where it runs, and which cloud identity it will use. The gateway gets approved access through that identity, then the team records the link between the cloud record and the physical equipment. That sounds basic, but it prevents a lot of cleanup later. Without a defined enrollment process, teams tend to copy settings from the nearest working gateway.

23:57 The new unit inherits an old credential, an old name, and sometimes an old set of assumptions about which machines sit behind it. It comes online quickly, which feels like progress, but nobody can later tell whether a data problem belongs to the new gateway or the source it copied. A proper enrollment path gives the new gateway its own cloud identity from day one. It also gives the OT team a clear handoff point. They can confirm the equipment sits on the intended line and reads the intended sources, while IT can confirm the connection only has the access it needs. You want both checks before the first shift depends on it. Replacement is where this design earns its keep. Imagine an edge computer fails after a power event. The technician swaps the hardware, restores the gateway software, and needs the data path back without asking every downstream team to change reports, pipelines, or asset mappings.

24:41 The physical box changed. The production role did not. Your architecture needs to decide which identity follows the role and which identity belongs only to that specific piece of hardware. There isn't one answer for every plant. What matters is that the process is deliberate, documented, and safe. For example, the line for gateway role may stay constant in your data model because it remains the same source for line-level telemetry. Yet, the replacement hardware has a different serial number, different local security material, and a different service record. If the new unit simply takes over the old cloud device ID, you need a controlled credential change and an audit trail that records the replacement. If you assign a new cloud device ID instead, your integration needs to preserve the relationship between the old and new device records.

25:22 Otherwise, dashboards and data pipelines may treat a hardware swap as a new production line appearing from nowhere. This is why names matter, but they don't solve identity by themselves. An asset identity describes the equipment's operational role. It might identify a line gateway, a packaging cell, or a specific machine in your asset hierarchy. A physical serial number identifies the hardware unit the vendor built. A cloud device ID identifies the connection that Azure recognizes. Those three values may point to the same thing for a short period. Over time, they often separate. A gateway can move to another line. A failed unit can be replaced. One gateway can collect data from many assets. A serial number can change while the production role stays the same. If you force one identifier to do every job you create records that look neat until the first replacement or rework project.

26:05 Keep the links explicit instead. The same applies when a device becomes suspect or reaches end of life. You should be able to disable its cloud access without disrupting every other line. A retired gateway shouldn't keep sending stale messages because its old configuration survived in a cabinet somewhere. A gateway under investigation shouldn't force a site-wide credential reset just to stop one connection. The operational action needs to stay narrow. That means your retirement process should include both sides of the relationship. The cloud identity gets disabled or removed according to your retention and audit rules while the asset record shows that the physical unit left service or moved elsewhere. If a replacement takes over the role record that connection clearly. Don't leave two records that both claim to represent the same life gateway. This isn't paperwork for its own sake.

26:46 When a quality engineer sees a gap in production data or security asks which device connected last night, the team needs a traceable answer. A clean life cycle model turns a hardware change into a controlled update instead of a small mystery that stays buried until it breaks a report. And once the device can join, change, leave, and return in a controlled way, it also needs a known configuration state. Device twins, desired state, and reported state. Once a gateway has a stable identity and a life cycle record, you need a way to describe its current operating condition without turning every setting change into a separate support ticket or a custom database workflow. That is what a device twin is for. It is a persisted cloud document attached to a device identity, holding metadata and the latest known state that both the cloud side and the device side can work with.

27:30 Think about it as a shared record with two writers, but not two people editing the same line at once. The cloud records, what it wants the device to use, the device reports what it actually uses. Those are related, though they must stay separate because a requested setting and an applied setting aren't the same fact. IoT Hub calls the cloud requested side desired properties that calls the device observed side reported properties. Say the engineering team wants every line for gateway to use a new sampling interval for a set of energy signals. They write the target interval into the desired properties. The gateway sees that request, checks whether the change fits its local rules, applies it if allowed, then writes its active interval back as a reported property. You can now see both sides of the conversation. The desired property might say, sample this signal every 10 seconds.

28:14 The reported property might say, I now sample every 10 seconds. Or it might report a reason why the gateway kept the previous setting. Maybe the local source does not support that rate. Maybe the gateway needs a planned restart. Maybe the configuration package failed validation. That gap is useful information. Without it, a cloud team can assume it changed a setting because a deployment tool returns success, while the equipment on the floor continues with the old behavior. A twin gives you a place to compare intention with observed condition. It doesn't make the device obey. It makes the difference visible. This is especially helpful with intermittent connections. A gateway can lose its cloud path during a network outage, a maintenance window, or a local restart. The cloud can still write the requested configuration into the desired state while the gateway remains offline.

28:58 When the gateway reconnects, it reads the target state and reconciles it with what it currently runs. That is different from sending a one-time instruction into a connection that may not exist at that moment. The requested state persists. The gateway can process it when it returns and then report what happened. For routine configuration, that is usually the behavior you want. A few manufacturing examples make this concrete. You may use desired properties to state the approved Edge software version for a gateway group, a recipe mapping version that a data collector should apply, or the permitted sampling interval for a certain data set. Reported properties can record the version actually installed, the recipe mapping currently active, the time of the last successful configuration check, and a summary of gateway health such as available disk space, or the status of a local collector.

29:39 Keep those values practical. A twin is useful when someone needs to ask, what does this gateway run now? Or did it apply the version we requested? It is not a place to bury every machine value because the document happens to accept Jason. Don't put high-frequency telemetry into a device twin. Temperature samples, cycle counts, current readings, vibration values, and raw status changes belong in an event path built for time-based data. A twin only needs the current condition that helps you manage the device. And if you update it for every sensor reading, you turn state synchronization into a noisy metric store, add unnecessary operations, and make the current state harder to read. Picture a gateway reporting its health once in the twin, software version, last configuration sink, local storage status, and whether each collector runs.

30:26 That is useful. Now picture it writing a new twin update every time a PLC tag changes. Soon the twin becomes a poorly designed historian, which is an expensive way to learn that a state document isn't a time series store. The split is simple. Use the twin for the latest known state and the requested target state. Use telemetry for the stream of facts over time. That also keeps recipe and configuration work honest. A desired recipe version in the cloud does not prove the machine runs that recipe. The reported state gives the gateway a way to confirm what it applied while the local control system remains responsible for the machine side rules. State describes what should be true and what the device reports is true now. Commands solve a different problem. They ask the device to take an action.

31:06 By directional communication without pretending it controls the machine. A connected gateway does more than send telemetry upstream. It can also receive messages from the cloud, respond to direct methods and reconcile changes in its configuration. Those parts sit alongside each other, but they shouldn't be treated as one generic channel. Device to cloud telemetry reports what the gateway sees. Cloud to device communication asks the gateway to do something or makes it aware of something. The direction changes and so does the responsibility for handling the message. Take a support case where a gateway stops publishing a subset of signals. The cloud team may need it to collect a diagnostic bundle, check a local service, or report the status of its OPC UA connections. That request isn't telemetry.

31:47 It is a targeted request directed at one known device. A direct method fits that sort of interaction. With a direct method, a cloud application calls a named operation on a connected device and receives a response. The device can accept the request, reject it, report an error or return a result. It gives the support team an immediate conversation with the gateway, rather than dropping a request into a channel and hoping someone eventually sees it. That doesn't mean the action itself finishes immediately. A request to gather diagnostic files may begin quickly, while the actual file collection takes longer. A request to validate a connection may return a basic result, while deeper fault checks continue locally. The method response should tell the cloud what the gateway did with the request, not pretend that every real task completes inside one round trip.

32:30 That distinction keeps the interface honest. Direct methods work best for actions where the device is online, and the caller needs a near immediate answer. Ask the gateway to reload a safe local mapping, ask it to run a health check, ask it to return its collector status. The device owns the implementation and can enforce its local rules before anything changes. Now if the gateway is offline, a direct method can't reach it. That isn't a flaw. It is simply the wrong interaction pattern for a change that must wait. For settings that need to survive disconnection, use desired properties. The cloud records the intended configuration, and the device checks that configuration when it reconnects. This works well for a new reporting policy, an approved software target, or a request to enable a defined diagnostic mode during the next maintenance window.

33:12 The cloud sets intent. The gateway decides how to apply it safely. That last part matters a great deal in manufacturing. People sometimes see cloud to device messaging and assume they can now control a machine from a dashboard. Technically they may be able to send a request architecturally that does not grant the cloud authority over the process. The PLC remains the local control authority. Safety controllers remain responsible for safety functions. Machine interlocks, hardwired circuits, and approved control logic don't become optional because an Azure service can send a message to an edge device. Keep the boundary firm. A cloud application can request a gateway to refresh a configuration, collect an approved data set, or ask the local system to evaluate a permitted operation.

33:53 The gateway should validate that request against local conditions, user rights, and the limits agreed with OT. If the line runs a critical production step, the gateway may reject the request, queue it for a planned window, or pass only a safe subset into the machine side logic. That is how the design should work. Picture a maintenance dashboard with a button labeled restart data collection. Behind that button, the cloud requests a restart through the managed gateway. The gateway checks whether its collector can restart without losing required data, whether the local process permits it, and whether a technician has placed the system in the right maintenance state. The button does not reach into a PLC and starts switching outputs. Good, it shouldn't. This isn't about making cloud integration less useful.

34:33 It makes it usable in a plant where uptime, safety, and process ownership matter. Bidirectional communication gives you a controlled way to manage the digital edge. It does not replace the control system that runs the physical process. Once the device relationship can support telemetry, requests, and persisted configuration, the data still needs to move beyond the device boundary. IoT hub telemetry, ingress, and routing. Once the gateway sends telemetry, IoT hub receives it through a device-aware endpoint. That wording matters because the incoming event arrives in the context of the device identity that connected, not as a packet from an unknown producer with a name typed into the payload. The telemetry can still contain the asset ID, line ID, signal name, source time stamp unit, and quality status that your downstream systems need.

35:14 But IoT hub already knows which register device submitted it. That gives you a clean connection between the data path and the managed source at the edge. From there, IoT hub routing decides where different messages should go. You define rules that inspect message properties, application properties, and device context, then send each category toward the right downstream path instead of forwarding every event to one shared destination. Say a gateway publishes normalized events from a line. A cycle-complete event may go to a stream processing path. A diagnostic message from the gateway may go to a storage path for support review. A device-related event may trigger a separate downstream action. The point isn't to create a routing rule for every imaginable condition. The point is to make the route visible and deliberate.

35:55 Without routing, telemetry often lands in one large bucket, and every consumer has to filter it later. That sounds flexible, but it pushes plant meaning into every downstream application. One team filters by line, another filters by asset type. A third team assumes that a missing property means something different. Soon you don't have a data contract. You have a collection of private guesses. Routing lets you keep the first split close to the device in-gress point. The gateway sends a defined event shape. IoT Hub identifies the source and applies the routing policy. Downstream services receive traffic intended for their job with the context they need to interpret it. That creates cleaner paths toward durable storage, stream processing, and operational consumers. For storage, you may route telemetry into a data platform that keeps the event history with the source time, receive time, and equipment context intact.

36:39 That path supports later analysis, traceability work, and reconciliation when a dashboard shows something odd. For stream processing, you may route selected events into a flow where several services can react independently. One consumer may calculate a near real-time production measure. Another may inspect condition data. A third may prepare a governed feed for a reporting layer. None of those readers should need direct access to the device connection itself. That separation keeps the edge relationship from becoming an enterprise-wide integration endpoint. It also means you should classify messages before you route them. If a gateway sends every value as generic JSON with no stable properties, the route can only guess based on payload fields that may change without notice. Give the event enough structure for routing to work reliably.

37:20 Include a message type, include source context, include the quality marker, when the gateway knows the source value is stale, substituted, or invalid. The data needs to carry its own operating context. IoT Hub also exposes an event hub's compatible endpoint for device-to-cloud telemetry. This can confuse people because event hubs style consumers can read telemetry using familiar streaming patterns and SDKs. A data engineering team may connect a consumer and process the stream without the device itself ever connecting directly to event hubs. That is useful. It lets the device-facing side and the stream-consuming side use the tools that suit their work. But compatibility doesn't collapse the services into one thing. The device still connects through IoT Hub under the identity and communication model you set there.

38:01 The downstream consumer reads a telemetry stream through an event hub's compatible interface. One side deals with the device relationship. The other side deals with consuming events. Think of a production record moving through a controlled handoff. The receiving team can process the record in its own system, but that doesn't mean it owns the machine that produced it. The interface gives access to the data, not ownership of the device lifecycle. You can also route telemetry to an event hub's instance when the wider platform needs a separate stream boundary, its own consumer setup, or a broader set of producers beyond managed devices. That choice depends on how you want to split the platform, not on a belief that the telemetry needs to change its identity halfway through the journey. This is where many teams start to assume IoT Hub and event hubs are identical.

38:42 They see events entering one service, then see those events consumed with event hubs patterns, and conclude that either service would have done the same job from the start. They wouldn't. But what IoT Hub does not replace. IoT Hub gives you a managed device boundary and a clean path for device telemetry. It does not become the answer to every data problem that happens to start on a factory floor. That sounds obvious until a plant creates one IoT hub, connects a few gateways, and then starts sending every available signal through it because the path already exists. Soon, machine data, gateway logs, batch records, app events, test messages, and maybe a few mystery payloads all enter through the same place. The service still receives them. That doesn't mean the design still makes sense. A high-rate producer may not need a device relationship at all.

39:23 Think about a trusted edge platform that already runs under side control and pushes a dense stream of normalized data into cloud analytics. If nobody needs to manage that producer as a cloud device, change its settings through a twin, or communicate back to it, IoT Hub ads functions the flow may never use. Don't treat device-aware ingress as a default tax on every event stream. This becomes more visible when the data rate climbs. Some data belongs close to the machine because it supports local control, fast protection, or operator response. Some data needs aggregation at the edge. Some data needs to leave the site only when it changes, crosses the limit, or supports a defined business question. Sending every raw point to the cloud does not create real-time visibility. It creates traffic. Take a typical PLC with a broad tag list.

40:05 You might have current values, set points, internal counters, intermediate states, heartbeat tags, and values that change several times during a normal machine cycle. If the gateway sends all of it, all the time, with no thought about meaning or use, the cloud receives a flood of records that few people can explain later. The problem isn't Azure capacity. The problem is that nobody decided what each signal is for. IoT Hub is also not your historian. A historian keeps industrial time series data for operational use, often with its own collection rules, compression behavior, source context, and shop floor access patterns. It has a different role from a device connection service, even if both touch the same temperature signal. Likewise, IoT Hub isn't an MES. It doesn't own production execution, work instructions, genealogy, quality process, or the definition of what complete means for a work order.

40:50 Feeding telemetry into Azure doesn't move those responsibilities out of the MES. And it isn't a data lake. A device-to-cloud event arrives with a payload and a connection context. A lake house or data lake needs govern storage, schema handling, retention decisions, data quality rules, and a way to join production data with business context. If you stop at the ingestion point, you haven't built a data platform. You've built an inbox. The same warning applies to the phrase digital twin. A device twin in IoT Hub tracks device site state and requested configuration. It does not model the whole factory. It doesn't understand product flow, material lots, machine relationships, process constraints, or the meaning of an OEE loss category, unless you build those models elsewhere. Calling a device twin a factory digital twin is a fast way to create confusion with a more expensive name.

41:34 So the edge layer needs to do real work before data enters the cloud. It should read the source safely, apply a clear data contract, attach the source timestamp and quality status, and decide whether to send a raw sample, an aggregate, an event, or nothing at all. That decision should follow the use case. If maintenance needs a vibration trend, define the rate, units, and quality rules that support that trend. If production needs cycle counts for OEE, send the cycle facts and the context needed to interpret them. If a signal has not changed and nobody can act on another copy of it, there may be no reason to send it again. Filtering isn't hiding data. It is defining useful data. You also need a contract that stays stable as gateway software and machine integrations change.

42:15 A downstream team shouldn't have to reverse engineer and undocumented Jason payload to learn whether a temperature value is in Celsius, whether it's time stamp came from the PLC, or the gateway, or whether a bad sensor value has already been substituted. Those details decide whether the event can support an operational decision. IoT Hub can enforce a managed connection. It can't repair a weak edge design or invent meaning for a stream of tags. You still need engineering judgment at the boundary between the machine network and the cloud. Once that boundary produces govern telemetry, we can switch from the single connected source to the next problem. How many independent systems need to read the same stream at the same time without waiting for each other? Event Hub starts with the stream. Event Hub starts from a different center of gravity.

42:56 You don't begin by registering a device and describing its state. You begin with a stream of events that producers need to publish continuously while other systems need to read that stream without coupling themselves to the producer. That difference sounds small, it isn't. A producer writes events into event hubs as they occur. It might be an edge gateway sending normalized machine data and application publishing logs, a web service recording user activity, or an integration service emitting events from a business platform. Event hubs doesn't need all of those producers to look alike. It needs them to put events into a stream that downstream systems can process. The event stream is a PEND only. A producer sends an event, event hubs accept it and readers consume it from the stream. The producer doesn't wait while an OEE service calculates a number.

43:39 It doesn't wait for a data engineering job to land the event in storage. It doesn't wait for a condition monitoring process to inspect the same reading. Each consumer works independently. Picture a site gateway sending a steady feed of normalized production events. One consumer reads the stream for a live operations view, another reads it for data preparation and later analysis. A third watches for patents in equipment condition. One reader may fall behind for a short time, restart and continue processing while the other readers keep moving. That is the stream model. The producer has one job, publish events. A consumer has its own job, read events and decide what to do with them. Event hubs keeps those jobs apart, which helps when different teams build different systems from the same operational data. You don't need to build a separate producer connection for every downstream use case.

44:22 That matters in manufacturing because a single production fact often has more than one consumer. A line stop event may feed an OEE view, a maintenance analysis path, a shift report and a longer term data platform. Those consumers won't always run at the same speed, deploy at the same time or fail in the same way. If they all depend on one direct integration, the slowest or least stable consumer begins to affect everybody else. Event hubs avoids that patent by keeping the event stream available for consumers to read on their own schedule. It is built for continuous traffic. Telemetry fits naturally because sensors and gateways produce time-based facts over and over. Logs fit because applications produce a steady record of what they see and do. Click streams fit because user actions arrive as a running sequence.

45:03 Gateway output fits because an edge layer can publish a controlled high volume feed without needing to know every downstream reader. The common point is not that the data comes from a device. The common point is that the data behaves like a stream. A gateway can publish one event every few seconds or it can publish a much denser flow from a group of machines. A cloud application can send its own events into the same broader platform. Event hubs treats these as producer traffic, then focuses on accepting the volume and making the stream available to consumers. It doesn't turn the stream into a device fleet. That means event hubs doesn't track whether a gateway needs a new configuration, whether a field unit has been replaced, or whether a cloud application should maintain a reported state document. Those concerns may exist in the wider architecture, but they sit outside the core job of the stream service.

45:45 This can be exactly what you need. Suppose a trusted edge platform already handles local connectivity, local certificates and side side operations. It needs to push a high volume data feed into cloud analytics where several teams need independent access. For that producer, the main question may be how much traffic the platform can ingest and how readers can process it without stepping on each other. Event hubs fits that shape well. But don't confuse broad acceptance with a lack of discipline. The stream still needs event types, source context, timestamps, and a data contract that downstream teams can trust. Event hubs moves events efficiently. It doesn't decide whether your machine state means running idle, blocked or waiting for material. The producer still needs to publish data people can use. So when you see event hubs in a factory architecture, think less about devices and more about flow.

46:28 Producers publish a continuing sequence of events. Consumers read that sequence independently. The service handles the pressure of moving data through the platform while the teams around it decide what each event means. That design depends on how the stream splits work across parallel paths. Partitions explain that next. Partitions. Parallel lanes for factory telemetry. Event hubs can accept a large stream because it doesn't treat the whole stream as one-ordered sequence. It divides the stream into partitions and each partition holds an ordered sequence of events. Think of a partition as one lane with its own history. Events within that lane retain their order. If a gateway publishes event A and then event B into the same partition, a consumer reading that partition sees A before B.

47:08 That guarantee stays inside the partition. It does not apply across the whole event hub. This catches people out when they first design a factory stream. They see a line stop event from line two and a cycle event from line five. Then assume the system can give them one exact global order across both. It can't and in most cases it shouldn't try to. Those events came from separate sources through separate network paths with separate clocks and separate local delays. A factory doesn't produce one universal timeline. Even inside one plant a source timestamp and the time asher receives the event can differ. A gateway might buffer data during a short network outage. A PLC clock might drift. One edge process may publish a batch a few seconds after another. So forcing every event through one partition just to get a single sequence creates a bottleneck while still failing to solve the real-time problem.

47:51 What you need is order where order has business meaning. For a single machine, you may choose the machine or asset ID as the partition key. Events from that machine then stay in the same partition. So consumers can process its cycle start, cycle complete, fault and reset events in order. For line level calculations you may choose the line ID. That keeps related events from the same line together which can help when the consumer calculates state across several machines that belong to one production flow. A gateway ID can also work. This fits cases where the gateway creates a normalized stream and the gateway itself owns the order of the data it publishes. The choice depends on where your data contract defines the source boundary. Don't pick a partition key because it feels neat in Jason. Ask what sequence a downstream process actually needs to preserve.

48:34 If an OEE process calculates availability per machine, machine level order may matter more than plant-wide order. If a gateway sends aggregates for a whole cell, the gateway may be the right boundary. If a quality process follows a batch through one line, the line or batch context may belong in the partition decision. Each choice creates a trade-off, put everything from one side into a single partition and you protect order for that site, but you limit how much parallel processing the consumers can do. Split events too broadly and consumers gain more parallel parts, but any logic that needs one ordered sequence across related events becomes harder. The answer isn't maximum partition count or minimum partition count. The answer comes from the unit of work that must stay ordered. Picture a packaging line with several machines.

49:16 You don't need the Kappa's vibration reading to arrive before the fillers energy value across the entire plant stream. But if you calculate the Kappa state from a run event, a shortstop and a fault reset, those events need a stable sequence for that machine. That is where the partition boundary earns its place. Partitions also set a practical ceiling on consumer parallelism. A consumer application can spread work across partitions, but it can't create useful parallel readers beyond the available partitions for one consumer group. If you create two few partitions, a growing analytics workload hits a limit that code alone can't fix. More compute won't create more ordered lanes. This is why partition planning belongs early in the architecture review. Estimate the volume, yes, but also identify how the work divides, which assets produce the traffic, which groups of events need local order?

50:00 How many parallel processing paths will the busiest consumer need when the plant expands or a second site joins the platform? You don't need to predict every future program. You do need to avoid designing a stream around the assumption that one consumer will always stay small. There is another detail worth keeping in mind. A partition key should remain stable. If the same machine sometimes publishes under its asset ID, sometimes under a gateway name, and sometimes with no partition key at all, you lose the ordering behavior you thought you designed. The event contract needs to state which source field drives partitioning and why. That is architecture, not a transport setting. Once the stream splits into ordered lanes, each downstream reader needs to track where it is within those lanes. Consumer groups, checkpoints, and replay. Partitions decide how the stream divides into ordered lanes.

50:43 Consumer groups decide who gets their own view of those lanes. Think about the same production events leaving a line gateway. The OE service needs them to calculate runtime, stoptime, and production counts. A condition monitoring service reads selected signals for equipment health. A data lake ingestion job needs the full-governed feed. Quality analysis may read the same stream with different logic and different timing. Those systems shouldn't compete for one read position. A consumer group gives each downstream application its own position in the event stream. The OE consumer group can process events as they arrive. The data lake consumer group can process a larger batch. The quality team can change its logic or pause a job without causing the OE calculation to stop reading.

51:24 Same source data, separate responsibility. This sounds like a small technical setting, but it avoids a common design failure. Someone creates one consumer group, then several applications attach to it because they all need the data. Now those applications share progress. One process reads events, another process finds nothing, and the teams start arguing about missing data when the architecture simply gave them one shared cursor. That isn't fan-out, it's accidental competition. Give each independently owned processing path its own consumer group. If the OE calculation and the quality analysis process have different owners, different release cycles or different recovery needs, they should not share a read position. The same applies to an operational dashboard versus a governed data ingestion path.

52:05 You want failure in one path to stay in that path. Each consumer also needs to track its progress. That is where checkpoints come in. A checkpoint records the place where a consumer has safely processed events in each partition so it can resume from a known position after a restart. The word "safely matters". Don't checkpoint the moment an event arrives. First process the event according to your application rules. Write the result where it needs to go, confirm that work completed, then checkpoint the position. If the service stops before that point, it can read the event again when it returns. That means downstream systems must tolerate repeat processing. A stream consumer may see an event more than once around a failure boundary, so your OE logic storage path or quality process needs an idempotent approach where a repeated event doesn't create a false extra production count or duplicate record.

52:50 This is normal stream processing, not a defect, picture an analytics job reading events from a night shift. It processes several minutes of data, writes results, then the compute process fails before it records its latest checkpoint. When it starts again, it resumes from the earlier checkpoint and rereads part of that same period. The producer does not need to know. The gateway doesn't need to resend anything. The recovery stays in the consumer layer where it belongs. That separation becomes very useful when teams correct their own logic. Maybe the quality group discovers that a state classification treated a brief machine hold as a fault, maybe the OE calculation needs a corrected mapping for a plan stop. If the event still sits inside the stream retention window, the team can replay the relevant period through updated logic. They can test the correction against the events that actually arrived, rather than guessing from a dashboard screenshot.

53:36 Replay does not mean unlimited history. It means the stream keeps events for a configured period and consumers can move back within that available window. Once that period ends, event hubs no longer acts as the source for a backfill. Your consumer design needs to know this before someone promises that every past event can be recalculated on demand. Retention supports recovery and short term reprocessing. It doesn't replace a durable record of production history. There is also a practical discipline around replay. Don't point a corrected consumer at a large time range and let it override live outputs without a plan. Use a separate consumer group or controlled processing path, label the replay output, validate the result, then decide how it should affect the operational record. Otherwise, a fix for one classification rule can quietly rewrite numbers people already used in shift reports.

54:21 Consumer groups, checkpoints and replay give each team room to process the same telemetry without tying their success to every other team. But the stream only keeps that room for a limited time which leads to the next distinction. Temporary event retention is not permanent manufacturing record keeping. Retention is not a historian. An event hubs stream keeps events long enough for consumers to process them, recover from a fault, or replay a period after you correct some logic. That is useful. It is not the same as keeping an industrial record for years. Retention gives you a working window. A historian gives operations a managed record of process data over time, often with collection rules and retrieval patterns built around plant use. A lake house keeps data for broader analysis, governance, and joins with other sources.

55:02 An MS keeps execution facts such as what order ran, what material moved, and what the system accepted as complete. Those jobs overlap at the edges, but they aren't interchangeable. Picture a quality engineer six months later trying to explain why a batch crossed a process limit. The engineer needs more than a replayable event stream. They need the source value, the time at the source, the quality condition of that value, the asset that produced it, and enough production context to connect the reading to the batch and process step. If the only copy lived in stream retention, that investigation ends when retention expires. Land-governed telemetry, endureable storage early in the data path. That doesn't mean dumping every message into files and calling the job done. The stored data needs a known schema, version rules, and a contract that tells the next team how to read it.

55:45 A number without context is just a number. Take a temperature reading. Store the source timestamp from the PLC or Edge collector, because that tells you when the physical reading occurred. Keep the cloud received time too, because it shows when the platform saw the event and helps expose buffering or connection gaps. Carry the asset identity that links the value back to the machine or process location, not only the gateway that transported it. Then keep the quality status a value may arrive late. It may come from a source marked bad. The gateway may substitute a last known value after a connection failure. Those are different conditions and they should not disappear, just because all three can fit into a numeric field in a dashboard. Without quality context, a smooth chart can hide a broken sensor. This is where teams create a data swamp without noticing.

56:26 They collect a large volume of telemetry, keep it somewhere cheap, and assume future analytics will sort it out. Then somebody tries to compare line output with energy use, joins events through an inconsistent machine name and discovers that half the timestamps mean receive time while the other half means source time. The platform didn't fail, the data contract never existed, keep the historian focused on operational time series needs, keep the lakehouse focused on governed long term data and broader analysis, keep the MS responsible for execution records and the business meaning of production. Each system can receive facts from the same plant, but each system should own the facts that match its role. You don't need one giant system that claims to know everything. For example, an event stream may carry a cycle-complete fact into durable storage, where it can later support production analysis.

57:09 The MES may still determine whether that cycle belongs to a particular work order and whether it counts as accepted production. A historian may retain detailed machine signals that operators and engineers need for process review. Forcing one service to own all of that creates confusion, not integration. The design goal is traceability from the stored event back to its source, its time and its quality condition. When someone questions a number in Power BI, the team should trace it through the durable data record, the event contract and the source system that produced it. That is real-time visibility with an audit path behind it. Event hubs can accept traffic from many producers, but it doesn't know which machine sent an event. Authentication without device identity in Event Hubs. Event hubs can authenticate producers securely, but it doesn't treat every producer as a managed industrial device.

57:52 That distinction changes the sort of security question you can answer when an event arrives from a site, a gateway, or a backend system. A producer can connect through a shared access policy, often using a shared access signature, or through Microsoft EntraID with role-based access control. Both approaches can fit well when the producer is a trusted application, a managed gateway platform, or a cloud service that already runs under an enterprise identity. The access boundary sits around the Event Hubs resource. A shared access policy can ground rights, such as sending or listening to events. That policy may apply at the event hub's namespace level, or to a specific event hub, depending on how you set it up. EntraID gives you a cleaner fit for services that can use managed identities because the service receives permission through Azure role assignments rather than carrying a broad shared secret in application settings.

58:39 For backend systems that is often the right model, say a cloud integration service publishes normalized production facts into an event stream. It runs in Azure, uses a managed identity, and needs permission only to send into one defined event hub. You can assign that role, audit the service identity, and remove its access without distributing a replacement secret to every system that reads the stream. That is a sensible application to platform boundary. A trusted edge gateway can also send directly to Event Hubs when the site already controls the gateway as part of its own security model. Perhaps the gateway runs under centrally managed software. Its network path sits inside an approved zone, and the site team already owns local authentication, certificate handling, replacement, and incident response.

59:20 In that case, Event Hubs can receive the telemetry stream without trying to become the fleet manager. But the Event Hubs authorization model doesn't tell you which individual field device sits behind that gateway. It knows the client that authenticated to the stream. It doesn't natively maintain a separate enrollment record, credential enabled state, and lifecycle trail for every sensor, PLC connected collector, or machine adapter behind the connection. That isn't a missing checkbox. It is a different design center. Suppose 10 gateways share one-cent policy because it looked easy during setup. One gateway becomes suspect after an HPC exposure, and you need to stop only that source while the investigation runs. With a shared credential, you can't simply revoke one gateway through Event Hubs itself, rotating the credential effects every gateway that depends on it.

1:00:03 Now the incident expands. You need to distribute the replacement credential, confirm every gateway picked it up, watch for failed reconnects, and deal with whatever happens when a remote site misses the update window. A single questionable source turns into a broad change across several production paths because the security scope never match the operational scope that is shared access behaving exactly as designed. Even when each gateway gets its own producer credential outside Event Hubs, you still own the registry, enrollment rules, disable process, credential rotation, and link between that credential and the real equipment. You can build those controls, and some platform teams already have them. Just don't assume Event Hubs supplies them because it accepts authenticated events. It doesn't model a device fleet for you.

1:00:44 Microsoft Enter ID can reduce the reliance on shared keys, especially for managed workloads that can obtain tokens through a service identity. This works very well for cloud native applications. Integration services in gateways where Entra authentication fits the runtime and network design. A small unmanaged field device usually doesn't fit that patent cleanly. Many industrial devices can't run an Entra-aware client, some live behind machine networks with limited outbound paths, others get replaced by technicians who need a simple control onboarding process. More importantly, those devices often need isolated life cycle control, a way to approve one unit, suspend one unit, replace one unit, and track exactly which unit connected. Event Hubs doesn't provide that device control plane, so use Event Hubs authentication for what it does well.

1:01:27 Securing producer and consumer access to a stream, use shared access policies with care, keep permissions narrow, and prefer managed identities where your producer can support them. Then decide separately whether the event producer is really a trusted platform component or a field device that needs individual cloud side ownership. That decision usually starts with the gateway. Direct devices, edge gateways, and trust boundaries. The gateway decision comes before the hub decision. You first need to decide what should connect to the cloud at all, because a PLC, a sensor, and an industrial edge gateway don't carry the same network capability, security controls, or operational ownership. A direct cloud connection can work, but only where the device, network, protocol, and security posture supported.

1:02:07 If a device can maintain an approved outbound connection, protect its credential, handle reconnects, and fit the site's OT security rules, then direct connectivity may be reasonable. That is a narrow set of conditions in many plants. Take an older machine with a PLC that speaks Modbus TCP or a production cell with an OPC UA server inside a segmented machine network. Those systems weren't designed to hold cloud credentials, manage certificate rotation, or expose themselves directly beyond the site boundary. Trying to turn each controller into a cloud client usually creates a support problem that nobody wants to own. The machine should keep doing machine work. An edge gateways sits close to the equipment and deals with that local reality. It can collect OPC UA data from newer systems, pull Modbus sources, read approved interfaces from legacy PLCs, and bring those inputs into one controlled edge process.

1:02:54 That doesn't mean the gateway should become another uncontrolled data collector. Its job includes deciding what leaves the cell or line. Raw machine signals often contain rapid changes, internal states, duplicate values, and values with no use outside local control. The gateway can turn those raw inputs into govern telemetry with no names, units, source times, quality codes, and a clear source link. That is where you connect the dots between IT and OT. Say a PLC exposes several tags related to a motor. One tag shows the current operating state, another reports a fault code, another records a runtime counter, and several more only help the PLC execute local logic. A cloud analytics service doesn't need every internal bit just because it exists. The gateway should publish the facts that support a defined decision.

1:03:35 It may send a state change event when the motor moves from running to stopped. It may send a periodic aggregate for energy use. It may send a fault event with the code, the machine context, and the time at the source. Each message has a reason to exist, which makes the downstream data easier to trust. This also creates a clean trust boundary. On one side you have machine protocols, plant zones, local control rules, and equipment that may remain in service for many years. On the other side you have cloud identity, data processing, and enterprise consumers that need real-time visibility. The gateway is not just protocol conversion, it owns the handoff. When that gateway needs its own cloud-side identity, remote configuration, and a managed device relationship, IoT Hub fits naturally. You might need to change its data collection policy, inspect its reported software state, or remove its access during an incident.

1:04:20 Those are device management needs, even if the gateway represents an entire production cell, rather than one sensor. The physical source can stay behind the gateway. The gateway becomes the managed cloud device. Now consider a different case. A site already runs a trusted edge platform under central control, and that platform produces a dense, normalized telemetry feed for several analytics teams. Nobody needs a cloud-side twin for the producer. Nobody needs direct methods or device-level configuration through the cloud connection. The main concern is moving a large, continuous stream into analytics. Event Hub fits that path because the producer already sits inside a trusted operational boundary. It can authenticate as the gateway platform or service, then publish the telemetry stream for downstream readers.

1:05:00 The cloud doesn't need to pretend every source behind that gateway connects as an independent Azure device. That choice should follow ownership, not fashion. A direct device connection makes sense when the device can safely own that relationship. An edge gateway makes sense when it needs to protect and normalize the machine side before data leaves the side. IoT Hub fits the managed gateway pattern. Event Hub fits the trusted streaming pattern. And in a real plant, you often see both patterns in the same architecture. A production line architecture that uses both take one production line with a managed edge gateway sitting between the machine network and Azure. The gateway reads the approved machine interfaces, turns those inputs into a defined event shape and connects to IoT Hub as a known cloud device.

1:05:42 That gateway may represent one machine, a cell or the whole line. The scope depends on how you operate it, replace it, and support it. What matters is that the cloud has a managed relationship with the gateway, while the PLCs and machine components remain inside their normal OT boundary. The device identity lives in IoT Hub, so does the device twin that records the gateway's current software version, collector health, and active configuration. If engineering changes in approved mapping or adjusts the reporting rule, the requested setting goes through the twin and the gateway reports back what it actually applied. That gives operations and IT a shared reference point. Picture a line where a gateway update adds a new production counter from a packer. The cloud records the target configuration for that gateway.

1:06:23 During its next sync, the gateway validates the mapping against the local interface, loads it, and reports the active version. If it cannot apply the change, the gap stays visible instead of disappearing inside a deployment log. Meanwhile, the govern telemetry flows out of IoT Hub into event hubs. This creates a separate stream boundary for the data teams and operational consumers that need to process the same events in parallel. One consumer reads production states, cycle facts, and plan stop context to calculate near real-time OE. It turns raw line facts into measures people can discuss at the shift meeting. Availability, performance, and quality, based on definitions, the plant agrees on. Another consumer lands the governed events in durable analytic storage. That path keeps the telemetry available for later analysis, where it can join with quality records, energy data, maintenance history, or production plans without asking the live OE process to do every job at once.

1:07:13 Those two consumers read the same operational facts. They don't need to share code, timing, or ownership. You can add more readers when there is a real use case. A condition monitoring process may inspect equipment signals, an energy team may use a defined set of meter events. But the gateway does not need a separate connection for each team. And the IoT Hub device relationship does not turn into a direct integration point for every application in the enterprise. The enterprise systems should receive a different class of data. MES needs business relevant production facts in a governed integration path. For example, a confirmed count, a machine state that fits the plant's execution model or a traceable event linked to the right work order context. EIP needs even less of the raw shop floor stream. It may need consumption, completion, scrap, or inventory movement at a business boundary.

1:07:56 Neither system needs every PLC tag arriving at cloud speed. If you feed raw telemetry straight into a MES or ERP, you force those systems to interpret machine-level noise they were never built to own. Then a transient signal change becomes a business event and somebody spends the next week explaining why a work order appears to complete three times. Keep the translation explicit. The Edge Gateway produces governed telemetry. IoT Hub manages the gateway relationship and configuration. Event hubs distributes the stream to independent consumers. A production data service turns selected operational events into facts that match MES or ERP rules with validation and context before anything crosses into those systems. That is integration that actually works end to end.

1:08:37 Each layer owns a clear job and no layer has to pretend it understands every other layer's concerns. A line can run this pattern without forcing a false choice between IoT Hub and Event Hubs. The gateway needs management, identity, and configuration. The wider platform needs a stream that more than one consumer can read. Both needs exist at the same time. DataRateAlone doesn't select the service but it changes the pressure on every design decision. TelemetryVolume, send less, mean more. A high data rate changes the design pressure but it doesn't decide what data deserves to leave the plant. That decision starts with the question, nobody enjoys asking, who will use this signal and what will they do differently because they received it. Not every signal belongs in the same class.

1:09:18 A fast raw signal can support local analysis or a short diagnostic window. An aggregate can describe energy use, production counts, or average load over a defined period. An exception event records something that changed and needs attention, such as a fault code, a quality limit breach, or a machine state transition. Those are different data products. Treat them that way. Take a high-speed packaging machine. A current signal may change many times each second while the useful cloud question could be much simpler. Did the motor load remain inside its normal band during the last minute and did it cross a defined limit at any point? You don't need every sample for that answer. The edge layer can calculate an average, minimum, maximum, or other agreed measure over a time window. It can also send an exception event when the signal crosses a limit, changes state, or stays outside a range long enough to mean something that gives downstream consumers data they can act on instead of a stream full of short-lived variation that only makes sense inside the local control loop.

1:10:08 Sampling follows the decision, not the tag list. For a condition monitoring use case, you may keep a higher rate signal for selected equipment because the analysis needs that detail. For shift reporting, a periodic aggregate may work far better. For an OEE calculation, a change in machine state and a confirmed cycle fact often carry more meaning than a repeated scan of the same running bit. The message shape should match the job. This is where plants accidentally create expensive noise. A gateway discovers a large OPC UA address space. Somebody decides more data must be better and the platform starts pushing thousands of unchanged values upstream on a fixed interval. The cloud can receive them, storage can keep them, a dashboard can draw them, none of that proves the data has a use. If a tag holds the same value for hours, sending it every second doesn't improve real-time visibility.

1:10:51 It only creates more records for network links, message services, stream processes and storage paths to carry. Later, the data team has to filter repeated values before it can find the changes that matter. The waste travels with the data. Deadband rules, change detection, event-based publishing and sensible sampling rates help stop that. You don't apply one rule to every signal. A tank level may need a deadband, a machine state needs a change event, a production counter may need a delta plus the relevant source time. A fast quality signal may need a short burst of detailed readings only when a related process event occurs. That is a much more useful conversation than asking whether the cloud can ingest more messages. Every event also needs enough context to survive outside the gateway that produced it. Carry the unit with the value.

1:11:32 Carry the source timestamp. Carry a stable asset ID, not just the host name of the HPC, carry a quality code when the source reports a bad reading, a stale value, or a substituted value. Otherwise, the event arrives as a number detached from the equipment and conditions that gave it meaning. Imagine two temperature readings arriving in the same stream. One has a source time from the PLC and a quality status that marks it invalid after a sensor fault. The other has only a cloud received time and no unit. Both may look fine in a basic chart. Only one can support a serious engineering review. Context is part of the telemetry. High throughput services are built to carry a lot of events. Good, that doesn't remove the need for data discipline. It raises the cost of skipping it because a weak event contract spreads faster and reaches more consumers.

1:12:14 Send less when less answers the question. Send more only when the use case needs the detail and the data contract can explain it. Once you define that message shape and traffic pattern, the cost model becomes much easier to understand or cost device operations versus throughput capacity. Once you define the message shape and traffic pattern, you can cost the design without guessing. The mistake is looking for one simple price comparison because IoT Hub and EventHubs meet a different kinds of work. IoT Hub pricing follows device operations and message units. In its paid tiers, a device to cloud message counts in size blocks so a small payload can still consume one message unit and a larger payload can consume more than one. Cloud to device traffic also counts. And the exact impact depends on the tier and the operations you use.

1:12:56 That means payload design shows up on the bill, a gateway that sends a compact, meaningful event behaves very differently from one that sends a large JSON document full of unchanged values every few seconds. The cloud may receive both without trouble, but the first design spends message capacity on operational facts while the second spends it on repetition. IoT Hub also carries work beyond telemetry. Device Twin reads, writes and queries have their own metering behavior so do actions tied to device management and two-way communication. If your team pulls large twin documents across a broad fleet because it seems easier than event-driven updates, that choice becomes visible in both cost and load. TwinState should change when state changes. EventHubs starts from another cost model.

1:13:37 You plan around stream capacity, ingestion volume retention and the amount of data consumers read. In the commenteers, throughput capacity controls how much data can enter and leave the stream over time. Higher volume, more consumer activity, and longer retained data, all change what the platform needs to carry. This is why event counter-loan can mislead you. A million tiny events and a million large events don't create the same traffic profile, nor does one reader behave like five separate consumer groups processing the same stream. If an OEE service, a data ingestion job, and a condition monitoring process all read the same telemetry independently, the stream design needs to account for those read paths. The capacity plan needs normal operation first. Measure what align, sell or site sends during a normal shift, then look at the events that change the picture.

1:14:20 Startup, recovery after a network interruption, a gateway reconnecting with buffer data, or several sites publishing at the same time. Average load rarely explains the problem. A system can look cheap and calm in a test environment, then hit pressure when a site reconnects and sends a backlog while downstream consumers also catch up. That doesn't mean you should overbuild every stream for the worst imaginable day. It means you need to know where bursts come from and what the system should do when they arrive. Retention needs the same kind of thought. Keep enough event history for consumer recovery and plan replay but don't pick a retention period because somebody wants as much as possible. Retain stream data has a job. Define that job then size it around the recovery window and the way your teams actually operate. The price-only argument usually starts with a chart that compares ingestion cost.

1:15:03 Event hubs may look cheaper for a dense telemetry feed and sometimes it is the better choice. But if the same design also needs per device enrollment, isolated credentials, disabled controls, configuration state and cloud to device communication, those needs don't disappear because the stream endpoint costs less. They move into custom code and support processes. You might build a device registry. You might build token issuance, credential rotation, remote configuration, audit records and an incident procedure that can isolate one compromised gateway without disturbing the rest of the plant. None of that appears in the initial event hubs estimate yet somebody will own it after go live. Cost is not only the monthly Azure invoice, it is also the operating work you create around the service.

1:15:44 The right comparison asks what each service removes from your own platform backlog. IoT Hub can justify its cost when you need its device functions. Event hubs can justify its cost when you need sustained streaming capacity and independent consumers. A mixed architecture can justify both when each layer carries the work it was built to handle. The expensive part often arrives after procurement when the team discovers which missing capability it now has to build and run itself. On the hidden cost of building IoT Hub yourself, event hubs can look like the cheaper starting point you create a namespace, grant a producer permission to send, point a gateway at the endpoint and events start flowing. For a pure stream, that can be exactly right. But if that gateway is really a managed field asset, the work you skipped hasn't disappeared.

1:16:24 You've just accepted ownership of it. You now need a device registry somewhere else that registry needs to answer basic questions for every connected unit. What is this gateway? Who approved it? What site and line does it belong to? Which credential can it use? And whether it should still connect? Once the fleet grows, a spreadsheet and a folder of connection strings stop being a system. Then you need credentials that match that registry. Maybe each gateway receives its own secret. Fine, but where do you store it? How do you issue it? And how does a replacement gateway retrieve it without a technician copying a credential through a remote desktop session? Maybe you use certificates? That improves the trust model, but you still need enrollment, renewal, trust chains, expiry checks and a process for a device that returns from a long outage with an expired certificate.

1:17:06 None of this is impossible. It is work. The same pattern appears when the cloud needs to communicate back to the edge. A stream endpoint accepts producer events, but a managed gateway may also need configuration changes, diagnostics requests, or a way to report its current software and collector status. If you build this around event hubs alone, you need a command path, a way to route commands to the correct gateway, and a way to know whether the gateway received or applied the request. A message leaving the cloud isn't proof that a machine-side action occurred. You also need state storage. Someone will ask which collector version runs on each line, whether a gateway applied the current tag mapping or whether its local buffer is filling up after a network issue.

1:17:46 At that point, you need a store for desired state, reported state, version history, and rules for conflicts between them. The stream does not answer those questions by itself. It only records events that a producer sent. This turns into permanent operational work. Consider a gateway that fails in the middle of a production week. The replacement unit arrives, the technician installs it, and now it needs its approved identity, the correct configuration, and access limited to its own role in the data path. Without a device management layer, someone has to perform each of those steps through custom tooling or manual procedure. If that process isn't reliable, replacement becomes an integration event rather than a maintenance task. Security incidents create the same problem under more pressure. A gateway may show signs of exposure, and the team needs to cut off only that unit while leaving the rest of the site online.

1:18:31 Your custom registry must support that decision. Your credential setup must enforce it. Your support team must know how to prove that the gateway lost access and cannot reconnect with an old token. That process needs testing before an incident, not during one. Ordered requirements grow with the fleet. Early on, people only ask whether data arrives. Later, they ask which gateway connected, under which identity, from which site, with what permissions, and whether a configuration change came from an approved service or an engineer's temporary script. Those are fair questions. In a production system, we think it came from that gateway isn't a useful answer. You can build the audit trail yourself. You can join connection logs to a custom registry, track-issued credentials, record-changer-provils, and retain evidence for device replacement and revocation.

1:19:13 Some organizations already operate that kind of platform outside Azure, and if they do, event hubs can fit cleanly into their architecture. That is the condition that matters. Producer trust and life cycle already live somewhere else under real operational ownership. For example, a centrally managed edge platform may already enroll gateways rotate credentials, distribute configuration, track software versions, and isolate a failed node. If that platform publishes a govern telemetry stream, event hubs can take over at the streaming boundary without pretending it needs to manage the edge fleet. Use event hubs directly when that control plane already exists and people can run it. Don't select it because the missing control plane looks invisible in a first architecture diagram. And there is a mirror image mistake. IoT Hub can also become the wrong choice when teams treat it as a universal pipe for every event the company produces.

1:19:56 The hidden cost of forcing every stream through IoT Hub. The reverse mistake causes just as much trouble. A team discovers that IoT Hub can accept telemetry, root messages, downstream, and connect to device-focused services. Then every stream in the company starts heading toward one IoT Hub because it feels safer to have a single front door. That front door turns into a crowded loading dock. Take a trusted gateway platform that already owns local security, software rollout, and site operations. It publishes a dense flow of normalized telemetry for a condition model or a central data platform. If nobody needs the cloud to manage that gateway through its IoT Hub identity, twin or command path, sending every byte through IoT Hub spends device message capacity without using the device functions that drove the choice.

1:20:39 The gateway traffic may still work, that isn't the test. The question is whether the architecture receives anything useful in return for putting that stream through the device layer. If the answer is no, you have turned a stream problem into a device messaging problem, then paid for the extra step because the service name included the word IoT. That gets expensive in less obvious ways too. A large gateway payload counts differently from a small, focused event. A burst after a site outage can consume capacity quickly. If the gateway sends many high frequency events only because the pipeline points at IoT Hub, the team may start shaping telemetry around a billing boundary rather than around the use case. That is backwards. Application logs create another form of confusion. A cloud service writes an error record, a data pipeline emits a processing event.

1:21:21 An integration service records a failed call to an MES interface. None of those are device telemetry even if the event relates to a machine or production line. They come from applications, treat them as application events, putting them into IoT Hub makes the platform harder to read. Someone looking at device traffic now sees a mix of real gateway telemetry, deployment logs, backend failures and internal service events. The messages may all reach the cloud, but their source ownership, security model, and operational meaning differ. One bucket hides those differences until somebody needs to investigate a fault. Imagine a production dashboard shows missing machine data. The team opens the IoT Hub metrics and sees a spike in messages, but many of those messages came from an application retry storm. The gateway feed may be healthy.

1:22:02 The data path may be healthy, yet the shared hub has mixed unrelated traffic into one operational signal, so nobody can tell what needs attention without more digging. That isn't central control, it's central confusion. A hub also becomes hard to govern when every producer uses it for a different reason. One team sends gateway telemetry, another pushes application traces. A third sends integration events because their existing code already knows how to write to the endpoint. Soon naming rules drift, schemas drift, access rules spread, and nobody can explain which messages deserve device level handling. The hub becomes a vague central bucket. You want boundaries that match ownership. Managed device traffic belongs on a path where device identity, configuration, and cloud-to-edge communication matter.

1:22:44 Trusted backend services and analytics platforms should publish their own streams where application identity throughput and independent consumption define the problem. The same factory platform can use both without duplicating everything. For example, an edge gateway might connect through IoT hub because the plan needs to know its approved configuration and current software state. That gateway's operational telemetry can then feed downstream stream consumers through the planned path. At the same time, a cloud integration service can write its own process events directly into event hubs under its own service identities. Those producers don't need the same doorway. Keep the separation visible in names, access rules, event contracts, and ownership. A gateway team should know which traffic it owns. A data platform team should know which streams it owns.

1:23:27 An application team should not need to pretend its logs came from a field device just to join the platform. Clean boundaries reduce the amount of custom explanation people need during an incident. So don't select IoT hub as a universal pipe just as you shouldn't force event hubs to become a device management platform. Put managed devices where device functions matter. Put trusted high-volume producers where stream functions matter. Then compare the common factory use cases one decision at a time. Use case decisions, machine connectivity and remote configuration. Let's put the decision into a real operating case. You've got a machine gateway on a line and it collects approved data from the equipment, publishes telemetry, and needs support over its full working life. That gateway needs its own identity in the cloud.

1:24:07 It also needs settings that can change without somebody standing beside the cabinet with a laptop. That points to IoT hub. The gateway might need to report its software version. Its active collector rules, its local disk use or whether it can still reach the machine interfaces it depends on. Engineering may need to request a new sampling rule or an updated tag mapping while the gateway reports which version it actually applied. Those are not stream questions. They are managed device questions. Think about a gateway replacement after an edge PC fails. The replacement unit should not arrive with a copied connection string from the old unit and a vague set of manual setup notes. It should enroll as the approved replacement, receive the correct identity and settings, then report that it has connected and applied its assigned configuration. That process needs to work during a busy production week.

1:24:49 IoT hub gives you a proper place to manage that relationship. The cloud can identify the gateway, control whether it can connect and retain the intended configuration while the unit comes online. If the site network drops for a while, the requested configuration does not vanish just because the gateway missed a message. When it reconnects, it can reconcile against the current desired state that makes offline periods manageable. Certificate rotation fits the same pattern. A gateway identity should not depend on one long-lived secret that survives for years because replacing it sounds inconvenient. With a managed device path, you can plan credential rotation around the device lifecycle, test it, monitor it, and isolate problems to the unit involved. A field device will eventually need replacement, repair or quarantine. Your architecture should treat that as normal work, not an exception that forces changes across the whole telemetry platform.

1:25:34 Remote configuration also needs a clear boundary. A cloud service can request that a gateway changes its reporting interval enables a new approved data point or starts collecting diagnostic logs for a limited period. The gateway receives that request validates it against local policy and applies it only if it is safe and valid. The gateway remains the enforcement point near the equipment. This matters most when people start using words like command and control. Azure can request an action from a gateway. That does not mean a cloud workflow should bypass planned safety logic and directly tell a PLC to start a motor, change a set point or defeat an interlock. The PLC owns machine control, safety systems own safety. A cloud command should pass through edge logic that knows the machine state, the local permissions and the rules for that action.

1:26:16 A request to collect a diagnostic trace is one thing. A request that changes production behavior requires a much tighter local approval path if it belongs in the designer tool. You need a traceable decision path from cloud intent to edge validation to any machine side effect. Otherwise, you have connected IT to OT without defining who still has authority when something goes wrong. Meanwhile, the gateway's telemetry does not get trapped inside the device management path. It can still reach stream consumers through IoT Hub rooting or through the event hub's compatible endpoint. The OEE process can read the production facts it needs. A data platform can land the governed feed for later analysis. A condition monitoring service can process selected signals on its own schedule. The device relationship and the data stream can separate cleanly.

1:26:56 That is the pattern for a managed machine gateway. IoT Hub owns its cloud identity, configuration, status and life cycle. The telemetry can then flow into the wider streaming layer without forcing every consumer to participate in device management. The next case removes most of those life cycle needs and puts the pressure somewhere else. Sustain stream volume. Use case decisions, high rate telemetry and analytics. Now take the other kind of production environment. You already run a trusted edge platform at the site. It owns the local connection to the equipment and its job is to push a dense, normalized feed into the cloud for analysis. That points to event hubs. Maybe the platform collects OPC, UA pub sub data from several lines, applies the site's tag model and sends a continuous stream of machine states, process values, alarms and gateway diagnostics.

1:27:43 Or perhaps it also sends application logs from the edge run time because those logs help the support team understand why a collector fell behind or lost a connection. Those are stream workloads. The producer already has an operational home. It runs under known site controls. The edge team owns its configuration and the cloud does not need to manage each source through a separate device record.