Un prototipo suele asumir una bancada confiable, un operador conocido y acceso físico sencillo. En campo aparecen redes desconocidas, reinicios desatendidos, cambios de propietario y años de actualizaciones. “Conecta de forma segura” no es un plan de lanzamiento. Esta guía convierte esa brecha en evidencias que un equipo pequeño puede verificar antes de distribuir y después mantener.
Enumera qué puede afectar el dispositivo, qué datos procesa, quién envía comandos, cómo se alcanza cada interfaz y qué ocurre sin conexión. Un sensor de temperatura tiene un impacto distinto a un relé que controla calefacción, puerta o bomba. Ajusta los controles al riesgo real y a su estado seguro ante fallos.
| Capa | Verificar antes de lanzar | Conservar como evidencia |
|---|---|---|
| Identidad y aprovisionamiento | Identidad única, sin contraseña compartida por flota, alta autenticada y revocación. | Registro de alta, responsable de credenciales y prueba de revocación. |
| Arranque y firmware | Secure boot cuando proceda, validación de firma OTA e interfaces de depuración controladas. | Firma/digest, procedencia del build, pruebas y recuperación demostrada. |
| Interfaces y red | Desactivar servicios innecesarios; autenticar comandos; limitar tópicos/API y solicitudes. | Inventario de servicios, política y pruebas negativas de autorización. |
| Datos y privacidad | Minimizar recolección, proteger datos en tránsito y reposo y definir retención/borrado. | Mapa de flujo, almacenamiento de claves y pruebas de borrado/restauración. |
| Backend y operación | Autorización por cliente en servidor, secretos fuera del firmware, auditoría y alertas. | Modelo de amenazas, revisión de acceso, runbook y responsable de vulnerabilidades. |
MAC e IP pueden cambiar, falsificarse o ser observables; trátalas como atributos de red, no como credenciales. Aprovisiona una clave o certificado por equipo mediante un proceso controlado, limita sus permisos y revócalo ante pérdida o retirada. Nunca grabes la misma clave privada en todas las unidades. Mantén secretos de producción fuera del código, repositorio, capturas, logs y paquetes de soporte.
No desactives anti-rollback sin una razón de recuperación documentada, pero tampoco publiques una actualización irreversible que pueda inutilizar equipos. Seguridad y recuperabilidad deben diseñarse juntas.
Usa TLS con validación de certificados: cifrar sin verificar el otro extremo puede conectar con un impostor. Separa autenticación de clientes MQTT/API de las cuentas de usuario. El servidor debe comprobar equipo y cliente, validar tamaño/esquema y exigir comandos con vencimiento e ID único. Limita reintentos con espera y variación para que una caída regional no provoque una denegación de servicio autoinducida.
La seguridad local debe sobrevivir a la pérdida de nube. Define modo seguro, control físico y comportamiento offline acotado para actuadores. Una alarma de humo, corte térmico o parada de emergencia no puede depender del panel.
Automatiza cuando puedas: bloquear dependencias prohibidas, probar firmware sin firma, acceso cruzado a tópicos, replay de comandos vencidos, mensajes inválidos, pérdida de red e interrupción de OTA. Ejecuta en el hardware real. La revisión manual cubre cambios de amenazas, datos, roles y soporte.
Publica contacto de seguridad y plazo de soporte. Define recepción, análisis, parche y comunicación de vulnerabilidades. Mantén versiones desplegadas y último contacto para localizar exposición. Al transferir o retirar, revoca identidad, desvincula cuentas, borra datos según lo prometido y conserva solo auditorías justificadas.
Un proyecto maker se vuelve producto IoT mantenible cuando cada equipo tiene identidad única, interfaces mínimas, actualizaciones autenticadas y recuperables, autorización en servidor, ciclo de datos y un responsable de incidentes. Cada punto debe ser una prueba o registro, no una casilla sin evidencia.