Connected devices are often deployed in places that are hard to supervise, run for years, and sit on networks that also carry other systems. A weakness in a single device can expose data, disrupt a service or provide an entry point into a wider infrastructure. Yet in many projects, security is treated as a final step: a review just before deployment, or a patch after an incident.
By then, the most important security decisions have already been made, implicitly, in the architecture. Retrofitting them is costly and rarely complete. Security works best when it is designed in from the start.
Begin with a threat analysis
Identify what needs protecting (data, the service, the devices themselves, connected systems), who might want to attack it, and how. Physical access to a device in a public space, interception of radio communications, a compromised back-end account: each scenario points to specific protective measures. This analysis keeps effort proportionate: you protect what matters most against the threats that are realistic.
Architectural decisions that make the difference
- Device identity: each device should have a unique identity and credentials, never shared or default passwords.
- Minimal attack surface: close debug interfaces and unused services, and expose only what the device needs.
- Protected communications: authenticate and encrypt exchanges between devices, gateways and servers.
- Least privilege: give users, services and devices only the access they need.
- Data minimisation: process locally where possible and transmit or store only what is necessary.
- Secure updates: a reliable, authenticated way to update software in the field, with a recovery path if an update fails.
- Logging and diagnostics: enough visibility to detect abnormal behaviour and investigate incidents.
Security across the whole lifecycle
Security does not end at deployment. Vulnerabilities are discovered in components over time, so plan how you will monitor them, how quickly you can deploy fixes, and how devices will be decommissioned securely at the end of their life. Document the security choices and their rationale: it helps operators, auditors and future developers keep the system protected.
Designing security into the architecture costs far less than adding it later, and it produces systems that operators can trust and keep under control.