The explosion of connected devices has transformed industries from healthcare to manufacturing. But with connectivity comes exposure. Every sensor, actuator, and gateway connected to the internet is a potential entry point for attackers. Building security into embedded devices from day one is not optional — it is a fundamental engineering requirement.

At Altirratech EU, we have designed, built, and deployed embedded systems across alarm monitoring, smart buildings, and industrial control. This article distils the security principles we apply to every project.

1. Secure Boot: The Root of Trust

Secure boot ensures that a device only executes firmware signed by a trusted authority. The chain of trust starts in immutable hardware — typically a boot ROM embedded in the MCU or SoC — and extends through the bootloader to the application firmware.

A typical secure boot flow:

1. Boot ROM loads and verifies the first-stage bootloader against a hardware-bound public key hash (fuses or OTP memory)
2. First-stage bootloader verifies the second-stage bootloader or application image signature
3. Application verifies any additional signed payloads (FPGA bitstreams, configuration files, updates)

If any signature check fails, the device enters a recovery mode or halts. This prevents unauthorised firmware from ever executing.

Without secure boot, a physical attacker with a JTAG adapter or a malicious OTA update can replace your firmware with their own. Secure boot is the first line of defence.

2. Hardware Security Modules and Secure Elements

For devices handling sensitive operations — cryptographic key generation, certificate storage, payment processing, or alarm signalling — a dedicated secure element is strongly recommended. These are tamper-resistant chips designed to protect secrets even if the main MCU is compromised.

Popular options include:

• ATECC608A (Microchip): I2C secure element with hardware key storage, ECDSA, and AES. Widely used in IoT authentication.
• SE050 (NXP): Common Criteria EAL 6+ certified, supports RSA/ECC/AES, and edge-to-cloud security frameworks.
• Optiga (Infineon): Used in automotive and industrial applications, supports up to EAL 6+.

These chips offload cryptographic operations from the main processor and ensure that private keys never leave secure hardware.

3. Secure Over-the-Air (OTA) Updates

An insecure OTA mechanism is one of the most common attack vectors in IoT deployments. Whoever can push an update can effectively own every device in the field.

OTA Security Checklist

• Signed update images: Every update payload must be cryptographically signed. The device verifies the signature before applying.
• Rollback protection: Use version counters stored in OTP or secure storage to prevent downgrade attacks.
• Encrypted payloads: Even though the transport (TLS) is encrypted, encrypting the payload at rest adds defence in depth.
• Atomic updates: Use an A/B (dual-bank) update scheme. If an update fails or is corrupted, the device boots from the working bank.
• Authenticated delivery: The update server should authenticate itself to the device using mutual TLS (mTLS).

# Example: A/B update partition layout
# Bank A: active firmware
# Bank B: staging area for updates
# Bootloader checks:
#   1. Is Bank B's image signed correctly?
#   2. Is Bank B's version > Bank A's version?
#   3. If yes: swap boot flag, reset
#   4. If no: boot Bank A

4. Secure Communication

Every IoT device needs to communicate with the outside world. The minimum bar is TLS 1.3 for TCP-based protocols and DTLS 1.3 for UDP-based protocols. But there is more to consider:

• Certificate pinning: Embed the server's public key or certificate hash in the firmware. Do not rely solely on CA validation — CAs can be compromised.
• mTLS (Mutual TLS): The device presents its own certificate so the server can authenticate it. This prevents unauthorised devices from connecting.
• Message-level signing: Even over TLS, sign critical telemetry and commands at the application layer. This protects against server-side breaches.
• Provisioning security: Devices should be provisioned with unique identities during manufacturing. Never ship devices with default or shared credentials.

5. Device Identity and Provisioning

Every device needs a unique, verifiable identity. The most robust approach is to generate a key pair on the device (or inside its secure element) during manufacturing and have it certified by a trusted Certificate Authority (CA).

The provisioning flow:

1. Device boots for the first time and generates an ECDSA key pair inside the secure element
2. The public key is signed by a manufacturing CA, producing a device certificate
3. The device certificate is stored alongside the private key (private key never leaves the secure element)
4. The cloud backend verifies the device certificate during the mTLS handshake

This approach ensures that:

• Each device has a unique, non-repudiable identity
• Private keys are never exposed in the supply chain
• Compromised device certificates can be individually revoked

6. Monitoring and Incident Response

Security does not end at deployment. Devices in the field need monitoring for anomalous behaviour. Key metrics to track include:

• Unexpected reboot loops — may indicate failed integrity checks or physical tampering
• Abnormal network traffic patterns — data exfiltration or botnet behaviour
• Failed authentication attempts — brute force attacks on device or cloud APIs
• Version distribution — devices stuck on old firmware versions need attention

Build a mechanism for remote logging and alerting during normal operation. When an incident is detected, you need a way to push a security patch to thousands of devices quickly and reliably.

Putting It All Together

Embedded security is not a feature you bolt on at the end. It is a design philosophy that touches every layer of the stack — from the silicon to the cloud. The cost of retrofitting security after deployment is orders of magnitude higher than building it in from the start.

At Altirratech EU, we treat security as a first-class engineering concern. Every project begins with a threat model tailored to the deployment environment, regulatory landscape, and business requirements. If you are building a connected product and need a partner who takes security as seriously as you do, let us know.