In DNP3, getting an event message onto the wire is only half the job - the outstation also needs to know the master actually received and processed it before it dares to forget that event. The application confirmation is the short reply that closes that loop. It is the difference between an RTU that can safely empty its event buffer and one that either loses alarms it thinks were delivered or replays old ones the master already saw. This guide explains what the confirmation is, how it differs from a data-link acknowledgment, and why a flaky telemetry link turns a missed confirm into duplicate or lost events.
DNP3 application confirm in one line: A DNP3 application confirmation is a message the master sends back to an outstation to acknowledge that it has received and successfully processed a response carrying event data. The outstation holds those events in its buffer until the confirmation arrives, then clears them, which is what makes DNP3 event delivery reliable rather than fire-and-forget.
DNP3 is built in layers, and two of them can each ask for a confirmation, which is a frequent source of confusion. The data link layer sits closest to the physical connection and can request a link-level acknowledgment that a single frame arrived intact at the far end. That confirm says nothing about whether anything above it understood or stored the data - it only proves the bytes crossed one hop of the link without a checksum error. On a clean point-to-point serial line it is often left off entirely because higher layers already provide their own checks.
The application confirmation lives at the top of the stack, where the actual DNP3 objects - the events, the analog and binary values - are assembled into a meaningful response. When an outstation sends a response and sets the confirm-requested bit in its application control field, it is asking the master to reply once it has parsed the whole fragment and taken ownership of the data inside. That acknowledgment is the one that matters for event integrity, because it is tied to the master's copy of the data rather than to any single frame surviving the wire.
The practical rule is that a data-link confirm protects a frame and an application confirm protects the events. An RTU can receive a perfectly good link-level acknowledgment for a frame that the master then fails to process, so relying on the lower layer alone is not enough when the payload is a batch of unrepeatable alarms. Confirmed application-layer service is what lets the outstation treat delivery as complete.
An outstation stores changes as events in a finite buffer, one per class of data, and each event sits there until the master proves it has been received. When the outstation sends those events - either because the master polled for them or because it pushed them as an unsolicited response - it flags the fragment as needing confirmation. It then starts a timer and waits. Only when the matching application confirmation comes back does it remove those specific events from the buffer, freeing the space for new changes.
If the confirmation does not arrive before the timer expires, the outstation assumes the events did not make it and retransmits them, still holding them in the buffer. This retry behavior is exactly what makes DNP3 dependable over lossy links: an event is never discarded on the mere hope that it was delivered. The cost is that the buffer can fill during an outage, and once it is full the outstation must either overwrite the oldest events or set a status flag telling the master that some events were lost, which the master then resolves with a full read.
The confirmation also carries a sequence number that ties it to the specific fragment it acknowledges. This lets the outstation tell one confirmation apart from another and avoid clearing the wrong events. It is a small mechanism, but it is the hinge the whole reliable-delivery model turns on: no confirm, no buffer clear, and the events stay put to be sent again.
On a marginal telemetry link - a fading cellular signal, a congested radio, a satellite hop with variable latency - the failure that hurts most is not the lost response but the lost confirmation. Picture an outstation that sends a batch of events, the master receives and stores them correctly, but the master's confirmation is dropped on the way back. The master already has the data, yet the outstation never learns that, so its timer expires and it resends the entire batch. The master now sees the same events twice, which shows up in a cloud SCADA history as duplicate alarms or a doubled event count.
The opposite failure produces lost data. If the confirmation timeout is set too short for a slow link, or if the outstation is misconfigured to clear events without waiting for a confirm at all, then a genuinely dropped response is treated as delivered and those events vanish. An operator looking at the trend later sees a gap with no indication that anything was missed, which is the more dangerous outcome because it hides the loss instead of merely repeating it.
For a platform like Merobix that ingests DNP3 events from many remote wells, tanks, and gathering sites over cellular and satellite backhaul, tuning confirmation behavior is part of getting the data right. Timeouts and retry counts have to suit the real round-trip time of each link, event buffers have to be sized for realistic outage lengths, and the master has to deduplicate on event timestamps and sequence so that a retransmitted batch does not double-count an alarm. Handled well, confirmations give clean, gap-free history even when the link underneath is anything but clean.
A data-link confirm acknowledges that a single frame crossed one hop of the link without a checksum error, but says nothing about whether the data was understood or stored. An application confirm is sent after the master has parsed the whole response and taken ownership of the events inside it. The application confirm is the one that protects event integrity, because the outstation waits for it before clearing events from its buffer.
Events represent changes that happened once and cannot be reconstructed, so the outstation cannot risk deleting them until it knows the master has them. By holding each event in its buffer until a matching application confirmation arrives, the outstation can retransmit if the confirmation never comes. This wait-and-confirm cycle is what makes DNP3 event delivery reliable over lossy links rather than fire-and-forget.
If the master receives and stores a batch of events but its confirmation is dropped on the return path, the outstation never learns delivery succeeded. When its timer expires, it retransmits the same events, and the master then records them twice. The fix is to deduplicate on event timestamp and sequence number at the master, and to set confirmation timeouts that match the link's real round-trip time.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.