Representative validation findings
The examples below represent real artifacts collected during device validation. They include both observed weaknesses and verification of implemented controls. All data is redacted and anonymized.
Wireless communication validation (Bluetooth LE)
Bluetooth Low Energy traffic was captured during normal device operation to verify whether communication was protected at the packet level.

Overall BLE capture showing advertising, connection establishment, and attribute access during normal operation.
Finding: Unencrypted Bluetooth traffic
Packet inspection revealed readable payloads prior to any authenticated pairing. Device identifiers and attribute data were observable in plaintext.

Specific BLE packet showing unencrypted payload data and exposed device attributes.
Why this matters: Unencrypted wireless traffic can expose device identity, operational data, or control interfaces to nearby observers.
Compliance context: Secure communication is required or expected under ETSI EN 303 645, EU RED cybersecurity provisions, and NIST IR 8259 guidance.
Network exposure assessment
Network interfaces were enumerated to identify exposed services and access paths. Testing was performed in an isolated environment.

Port scan results showing listening services and accessible network interfaces.
Controlled access & exploitation testing
Where exposed services were identified, controlled access attempts were used to validate authentication strength and monitoring behavior.

Credential brute-force testing performed in a controlled environment to evaluate access controls.

Reverse shell established in an emulated environment to validate detection and response behavior.
Embedded Linux & build-system validation
The device build system was reviewed to understand how security controls, logging, and monitoring could be introduced or validated.

Custom Yocto layer used to introduce security-relevant functionality and validation hooks.

Build flags and configuration affecting runtime behavior and security posture.
Network monitoring and logging validation
Initially, the device had no active monitoring or alerting for network activity. After implementing custom Yocto layers and using tcpdump, network traffic could be captured and analyzed to validate device behavior and security controls.

Network activity captured after implementing logging, illustrating visibility of device behavior.
Why this matters: Effective monitoring allows detection of unauthorized access attempts and provides forensic evidence for incident investigation.
Compliance context: Logging and monitoring are emphasized in IEC 62443 and NIST IoT cybersecurity guidance.
What these examples demonstrate
- Verification of wireless encryption through packet-level inspection
- Identification of exposed network services and access paths
- Controlled exploitation to validate authentication and detection
- Implementation and validation of monitoring and logging after build system adjustments
- Alignment of findings with IoT security compliance expectations
These examples are representative and do not constitute certification or approval. They demonstrate independent technical validation of device behavior.