How should organisations trust data coming from connected devices in IoT environments?

Organisations should trust IoT data only when they can verify the device identity, integrity, and transport security behind it. Each device needs a secure identity so the source can be authenticated, cloned devices can be rejected, and tampering can be detected. Sensitive telemetry should also be encrypted in transit and protected with controls matched to the device and connectivity type.

Why trust in IoT data starts with the device, not the dashboard

IoT telemetry is only as trustworthy as the device that produced it and the path it took to reach your systems. If the source cannot be identified, the data may be replayed, forged, cloned, or altered before it ever reaches analytics, automation, or operational decision-making. That is why device identity, integrity, and transport protection are the baseline for trusting connected-device data.

For connected devices, trust is not a general belief that the network is “safe.” It is a verifiable chain that ties a specific physical or logical device to a known identity, proves that the device is genuine, and preserves the data’s confidentiality and integrity while it moves.

A useful way to think about this is that data trust is a property of the whole path: enrolment, device identity, attestation or certificate status, message authenticity, and encrypted transport all have to line up. If any one of those is weak, the telemetry may still look valid, but the organisation has no strong basis to treat it as reliable.

What controls make connected-device data trustworthy?

The core controls are straightforward, but they only work when applied as a set. Devices need strong identities, typically backed by device certificates or similar cryptographic credentials, so a receiving system can authenticate the source rather than accept data from anything that can reach the endpoint. Where possible, the device should also prove its state, for example through attestation or posture signals, so the organisation can distinguish a real device from a copied credential or a substituted unit. NHIMG’s Device and IoT Identity Guide covers the identity and onboarding controls that make this possible.

Transport security matters just as much. Sensitive telemetry should be protected in transit with modern cryptography and authenticated channels, so attackers cannot read or alter readings between the device and the collector. In practice, that means the receiving platform should verify both who sent the data and whether the data arrived intact. If the device is also exposed to other systems or automation, zero trust thinking helps limit what that device can reach even after it is trusted for one purpose. NHIMG’s Zero Trust Identity Guide is a good fit for the access side of that model.

Trust also depends on lifecycle discipline. A device that was legitimate last year can become untrustworthy after repurposing, compromise, certificate expiry, or insecure firmware changes. Organisations therefore need onboarding, renewal, revocation, and offboarding controls that keep device trust current instead of assuming it is permanent.

How organisations avoid false trust in IoT telemetry

The most common failure is trusting data because it came from a familiar network, vendor, or application dashboard. That shortcut ignores the possibility that a device was cloned, its credentials were copied, or its firmware was modified. The result is telemetry that appears operationally normal but no longer reflects the true state of the physical world.

Another failure mode is treating encryption as proof of authenticity. Encryption protects confidentiality in transit, but by itself it does not prove the source device is genuine or uncompromised. Likewise, a device certificate alone does not guarantee the device is healthy if the certificate can be exported, reused, or stolen.

For organisations that operate across mixed IoT estates, the challenge gets harder when device types, connectivity methods, and update mechanisms differ. A control that is adequate for one class of device may be weak for another, especially where long-lived credentials, weak enrollment, or poor revocation handling are involved. Those environments benefit from explicit device trust criteria rather than one blanket assumption of reliability.

Risk and Threat Considerations

IoT telemetry can be attacked at the source, in transit, or through credential misuse. If organisations treat connected-device data as trustworthy without validating identity and integrity, they risk acting on forged readings, hiding a compromised device, or propagating bad data into operational automation and incident response.

Failure mechanism: An attacker clones a device identity, steals a credential, or tampers with traffic so a collector accepts synthetic or altered telemetry as genuine. Where device identity and transport protection are weak, the false data can persist long enough to distort monitoring, control actions, or forensic conclusions.

Impact: The organisation may make incorrect operational decisions, miss an actual safety or security event, or amplify a compromise through downstream systems that assume the data is authentic.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-9 — Service Identification and Authentication	IoT devices and collectors need mutual source authentication for telemetry trust.
	IA-5 — Authenticator Management	Trusted device data depends on secure lifecycle handling of device credentials and certificates.
	SC-8 — Transmission Confidentiality and Integrity	Telemetry trust requires protection against interception and tampering in transit.
Recommendation — Require authenticated device-to-platform sessions before accepting telemetry. Rotate, protect, and revoke device authenticators on a defined lifecycle. Encrypt and integrity-protect IoT traffic between device and collector.
ISO/IEC 27001:2022	A.8.24 — Use of cryptography	IoT telemetry trust relies on cryptography to protect data in transit and verify origin.
Recommendation — Apply cryptography to protect IoT data confidentiality and integrity.
CIS Controls v8	CIS-5 — Account Management	Device identities and credentials need lifecycle control to prevent stale or abused trust.
Recommendation — Inventory, review, and remove stale device credentials and identities.

Practitioner Guidance

What to verify: Treat each device as trustworthy only when you can verify its identity, its current trust state, and the protection on the channel carrying its data. If you cannot answer who the device is, what state it is in, and whether the transport is authenticated and encrypted, the telemetry should be treated as untrusted input.

Decision rule: If the device can influence alerts, automation, or physical processes, require stronger identity proof and revocation handling than you would for low-risk telemetry. If the device can only send observational data, the minimum bar is still source authentication and integrity protection, but the operational tolerance for weaker controls should be explicit and approved.

Practitioner takeaway: IoT trust is not granted by connectivity alone, it is earned by proving source identity, preserving integrity, and keeping device trust current across the full lifecycle.