Audita tu parque conectado antes de que lo haga otro.

No. Una certificación de laboratorio comprueba el producto contra una lista, por ejemplo ETSI EN 303 645, y confirma si están puestos los controles exigidos. Un pentest de IoT demuestra lo que un atacante puede hacer de verdad: si una unidad sobre el banco entrega una clave del cloud, una actualización para todo el parque o los datos de otro cliente. Un producto puede tener el certificado limpio y seguir siendo explotable de punta a punta. Casi todas las empresas que fabrican producto conectado a escala hacen las dos cosas: la certificación atada al lanzamiento del producto, y el pentest atado a las entregas de firmware, a las revisiones de hardware y a los hitos del parque.

Por las piezas que comparten todos los dispositivos. Una sola unidad sobre el banco suele revelar una clave incrustada, un endpoint de cloud o un mecanismo de actualización que es idéntico en todo el parque. Desde ahí, un atacante usa la API cloud compartida, el canal de actualización OTA o una separación débil entre clientes para pasar de un dispositivo a muchos. Por eso probamos siempre el camino que va de un solo dispositivo al parque entero, y no solo el dispositivo aislado.

Normalmente sí, al menos unos pocos. Auditar IoT de verdad significa hardware sobre el banco: abrir una unidad, leer sus puertos de depuración y extraer el firmware necesita el dispositivo físico. Solemos pedir dos o tres unidades de muestra, a ser posible con el acceso de depuración habilitado, además de acceso a la app móvil y al backend cloud. Cuando el acceso físico es imposible, acotamos a lo que sí se puede probar (imágenes de firmware, la app y el cloud) y lo decimos con claridad en la propuesta.

No. Trabajamos sobre unidades de muestra y entornos de staging, no sobre los dispositivos vivos de tus clientes, y cada proyecto va con sus reglas del encargo documentadas y un protocolo para los hallazgos críticos. Las pruebas de parque y de cloud se hacen contra un tenant de test controlado o con aprobación expresa, nunca como acciones destructivas en producción. Te llevas la visión del atacante sobre tu producto sin poner en riesgo los dispositivos que ya has vendido.

Un solo producto conectado con su backend cloud documentado suele llevar entre dos y tres semanas de pruebas activas, por el trabajo de hardware, firmware, radio y cloud que hay dentro; las familias de varios productos o las pilas de radio complejas llevan más. El alcance se acota antes y el retest va después de tus correcciones. El calendario lo confirmamos en la propuesta, que entregamos en las 48 horas siguientes a la primera llamada.

El precio sale del alcance: el número de dispositivos y de capas, los protocolos de radio que hay en juego, y si entra el backend del parque. Damos un precio cerrado, sin costes ocultos y sin obligación de renovar. Un proyecto enfocado a un solo producto está en la parte baja del rango; las familias de varios productos o los proyectos que necesitan hardware de radio especializado escalan desde ahí. El retest, contra la misma revisión de firmware y de hardware, va siempre incluido.

El hacker ético senior al que conoces en la primera llamada, de principio a fin. Nuestro equipo cuenta con credenciales OSCP, OSCE³, OSWE y OSEP, y en IoT sumamos experiencia de hardware, firmware y radio (herramientas como Ghidra, HackRF, Ubertooth y JTAGulator). Somos contribuidores verificados del Bug Bounty de la NASA con hallazgos publicados contra productos conectados. La misma persona acota, ejecuta y hace el retest. Es con quien tratas durante todo el proyecto.