¿Qué es la gestión declarativa de dispositivos? (2026)

La gestión declarativa de dispositivos (DDM) es el marco de trabajo de Apple que permite a los dispositivos aplicar sus propias configuraciones de forma local, sin tener que esperar instrucciones del servidor. Presentada en la WWDC 2021, cambia radicalmente el modelo de comunicación entre tu servidor MDM y tu parque de dispositivos Apple.

Si gestionas dispositivos macOS, iOS o iPadOS a una escala considerable, el DDM supone el cambio arquitectónico más significativo en la gestión de dispositivos de Apple desde que se introdujo el MDM en 2010. Esta guía explica qué es, cómo funciona técnicamente, cómo se integra con el MDM tradicional y qué debe hacer al respecto antes de que el calendario de obsolescencia de Apple le obligue a actuar.

Por qué el MDM tradicional tiene problemas de escalabilidad

Para entender por qué existe DDM, hay que comprender qué falla en el protocolo al que sustituye. El MDM tradicional funciona según un modelo de sondeo. El servidor envía un comando, el dispositivo lo ejecuta, el dispositivo envía un informe y el servidor envía el siguiente comando. Cada comprobación de estado, cada envío de configuración y cada instrucción de actualización de software pasa por este bucle de solicitud-respuesta.

Con 50 dispositivos, esto funciona bien. Con 5.000 dispositivos, el servidor tiene que gestionar miles de comprobaciones simultáneas. Con 50 000 dispositivos, acabas gestionando la infraestructura solo para gestionar tu propia infraestructura. Este modelo también genera brechas de cumplimiento: un dispositivo que no puede conectarse al servidor MDM simplemente no actualiza su configuración, y el servidor no se dará cuenta de la desviación hasta la siguiente comprobación que se realice con éxito.

También hay un problema más sutil. El MDM tradicional carece de estado desde la perspectiva del dispositivo. El dispositivo no «sabe» cuál es su estado previsto. Simplemente ejecuta los comandos a medida que llegan. Si un usuario cambia un ajuste entre registros del MDM, el dispositivo permanece en un estado de incumplimiento hasta que el servidor vuelve a sondearlo y emite una corrección.

Para comprender cómo funciona la gestión de dispositivos a nivel de protocolo, esta arquitectura de sondeo es la restricción fundamental que el DDM está diseñado para eliminar.

Cómo funciona la gestión declarativa de dispositivos

El DDM invierte el modelo de gestión. En lugar de que el servidor le indique al dispositivo qué hacer paso a paso, el servidor envía al dispositivo una descripción completa de su estado deseado. El dispositivo almacena esa descripción localmente y la aplica de forma autónoma, incluso sin una conexión activa con el servidor.

Así es como funciona en la práctica. Con el MDM tradicional, la instalación de un perfil de configuración requiere que el servidor envíe un comando, espere a que el dispositivo lo acuse recibo, confirme que el perfil se ha instalado y gestione cualquier error. Con el DDM, el servidor envía una declaración que dice: «este dispositivo debe tener esta configuración». El dispositivo se encarga de hacer que eso sea así y de mantenerlo a lo largo del tiempo.

Si un usuario elimina un ajuste gestionado, el dispositivo lo restaura inmediatamente, sin esperar al servidor. Si el dispositivo permanece sin conexión durante tres días, sigue aplicando el estado declarado. Cuando se vuelve a conectar, informa de lo que ha ocurrido durante ese intervalo a través del canal de estado.

Los tres pilares: declaraciones, canal de estado y extensibilidad

La arquitectura DDM de Apple se basa en tres componentes. Todo administrador de TI que trabaje con dispositivos Apple debe comprenderlos todos.

Declaraciones

Las declaraciones son documentos JSON estructurados que describen cómo debe ser y qué debe hacer un dispositivo. Existen cuatro tipos de declaraciones:

• Declaraciones de configuración: definen ajustes específicos del dispositivo, equivalentes a los perfiles de configuración de los sistemas MDM tradicionales, pero almacenados y aplicados localmente. Algunos ejemplos son las políticas de código de acceso, los ajustes de Wi-Fi y las configuraciones de VPN.
• Declaraciones de activos: hacen referencia a recursos externos de los que dependen las declaraciones, como las credenciales o los certificados necesarios para activar una configuración.
• Declaraciones de activación: definen los predicados que determinan cuándo debe aplicarse una configuración. Por ejemplo: «aplicar FileVault solo si el dispositivo está inscrito en el proveedor de identidad corporativo». Esta lógica condicional se ejecuta en el dispositivo, no en el servidor.
• Declaraciones de gestión: gestionan la información a nivel de inscripción, incluidas las propiedades de inscripción del dispositivo y la configuración del servicio MDM.

El sistema de predicados de las declaraciones de activación es una de las características más potentes e infravaloradas de DDM. En lugar de que sea el servidor el que ejecute la lógica para decidir qué dispositivos reciben qué configuraciones, se traslada esa lógica al propio dispositivo. Un dispositivo inscrito en el ámbito de su departamento financiero puede aplicar de forma autónoma ajustes de cifrado más estrictos que un dispositivo del ámbito de operaciones generales, basándose en criterios evaluados localmente.

Canal de estado

El canal de estado es el mecanismo de notificación asíncrono de DDM. Los dispositivos envían informes de estado al servidor cuando se produce un cambio significativo, no según una programación de sondeo. Si un dispositivo aplica una declaración con éxito, lo notifica. Si un predicado de activación cambia de estado, lo notifica. Si se instala una actualización de software, lo notifica.

Para los equipos de TI, esto cambia la forma de concebir la visibilidad del parque de dispositivos. En lugar de consultar el estado según un horario fijo, se recibe un flujo continuo de eventos de cambio. El inventario de dispositivos se mantiene actualizado casi en tiempo real sin generar una carga en el servidor proporcional al tamaño del parque. Un parque de 10 000 dispositivos genera tráfico de estado cuando se producen cambios, no 10 000 comprobaciones cada 15 minutos.

Esto también transforma la supervisión del cumplimiento normativo. Con los sistemas MDM tradicionales, las desviaciones se detectan en el momento del registro. Con el canal de estado de DDM, el dispositivo le informa de que ha detectado y corregido una desviación, o de que ha detectado una desviación que no puede autocorregir, inmediatamente después de que se produzca.

Extensibilidad

La extensibilidad permite que el marco de trabajo de DDM admita nuevos tipos de declaración a medida que Apple los va incorporando en las distintas versiones del sistema operativo. En lugar de requerir cambios en el protocolo cada vez que Apple introduce nuevas capacidades de gestión, la extensibilidad proporciona un mecanismo estandarizado para añadir nuevos tipos de configuración y de estado.

Esto es importante para la planificación a largo plazo. A medida que Apple siga ampliando la compatibilidad con DDM, tu plataforma MDM podrá adoptar nuevos tipos de declaración sin necesidad de cambios arquitectónicos fundamentales. Para los equipos de TI que evalúan proveedores de MDM, una plataforma con compatibilidad nativa con DDM basada en principios de extensibilidad será mucho más fácil de mantener a medida que evolucionen las API de gestión de Apple.

Gestión declarativa de dispositivos frente al MDM tradicional

Las diferencias prácticas entre el DDM y el MDM tradicional afectan a las operaciones diarias de formas que resultan importantes para los equipos de TI que gestionan flotas reales.

Conviene dejar claro el tema de la coexistencia: DDM no sustituye por completo al MDM heredado, al menos de momento. Ambos protocolos se ejecutan en paralelo en los dispositivos inscritos. Los comandos MDM siguen gestionando determinadas acciones, los flujos de inscripción siguen utilizando los canales MDM tradicionales y algunas funciones aún no se han migrado a DDM. Apple ha indicado que los comandos heredados para actualizaciones de software, restricciones y determinadas configuraciones quedarán obsoletos a partir de iOS/macOS 26, lo que convertirá a DDM en la vía obligatoria para esas funciones en el futuro.

Requisitos de versión del sistema operativo para DDM

La compatibilidad con DDM está vinculada a versiones específicas del sistema operativo de Apple. Antes de crear cualquier flujo de trabajo de gestión basado en DDM, comprueba la distribución de sistemas operativos de tu parque de dispositivos:

• iOS 15 / iPadOS 15 / macOS 12 Monterey: se introduce la compatibilidad inicial con DDM
• iOS 16 / iPadOS 16 / macOS 13 Ventura: Ampliación de los tipos de declaración y gestión de actualizaciones de software a través de DDM
• iOS 17 / iPadOS 17 / macOS 14 Sonoma: declaraciones de configuración adicionales, informes de estado mejorados
• iOS 18 / iPadOS 18 / macOS 15 Sequoia: Expansión continuada; nuevos comandos MDM heredados marcados para su obsolescencia
• iOS/macOS 26 y posteriores: Descontinuación significativa de comandos MDM heredados; DDM se convierte en la vía obligatoria para la aplicación de actualizaciones de software y tipos de configuración adicionales

Si tu parque de dispositivos cuenta con dispositivos que ejecutan versiones antiguas del sistema operativo, necesitarás un enfoque híbrido durante el periodo de transición. Cualquier dispositivo con una versión anterior a iOS 15 o macOS 12 no podrá utilizar DDM en absoluto y requerirá comandos MDM heredados de forma indefinida, o bien tendrás que excluir esos dispositivos de tu hardware compatible.

Implicaciones de seguridad de DDM para el cumplimiento normativo empresarial

El modelo de aplicación autónoma de DDM tiene implicaciones directas para la postura de seguridad que no resultan evidentes desde una perspectiva puramente de gestión de dispositivos.

Con el MDM tradicional, el estado de cumplimiento de un dispositivo es una instantánea de la última comprobación. Un dispositivo que modifica una configuración de seguridad a las 9 de la mañana y se registra a las 9 de la noche ha estado en situación de incumplimiento durante 12 horas. En entornos regulados que operan bajo marcos como el NIST SP 800-53 o los CIS Benchmarks para macOS, ese lapso constituye un fallo de control, aunque sea temporal.

El DDM elimina esa brecha. Dado que el dispositivo hace cumplir su propio estado declarado de forma continua, el intervalo entre el incumplimiento y la corrección se mide en segundos, no en horas. El canal de estado registra el evento, lo que proporciona un registro de auditoría que muestra la desviación y la corrección con marcas de tiempo.

Para las arquitecturas de confianza cero que se basan en señales de estado de los dispositivos para conceder o denegar el acceso, esto es de vital importancia. Un dispositivo que afirme cumplir con un motor de políticas, como un proveedor de identidad o una pasarela de SSO, debe proporcionar datos precisos sobre su estado. La aplicación local continua de DDM, combinada con los informes de estado en tiempo real, hace que las señales de estado del dispositivo sean más fiables de lo que pueden lograrlo las comprobaciones basadas en sondeos.

Esto se vincula directamente con una estrategia más amplia de seguridad de los terminales. Si considera la gestión de dispositivos y la seguridad como disciplinas integradas en lugar de funciones separadas, la arquitectura de DDM está diseñada para ese modelo integrado.

Aplicación de actualizaciones de software con DDM

La gestión de actualizaciones de software es el ámbito en el que las ventajas de DDM resultan más evidentes para los equipos de TI de las empresas y donde el calendario de obsolescencia de Apple genera mayor urgencia.

Con los sistemas MDM heredados, imponer una versión específica de macOS implica que el servidor envíe un comando de actualización, que el dispositivo lo acuse recibo, que el dispositivo descargue y prepare la actualización, y que el servidor realice un sondeo para confirmar que se ha realizado correctamente. Si el dispositivo está desconectado durante la ventana programada, la actualización no se lleva a cabo. Si un usuario la pospone, hay que volver a que el servidor envíe otro comando.

DDM gestiona las actualizaciones de software a través de la declaración de configuración de «Actualización de software». Se declara la versión mínima aceptable del sistema operativo. El dispositivo evalúa su estado actual en función de esa declaración, inicia el proceso de actualización de forma autónoma cuando se cumplen las condiciones e informa del estado a través del canal de estado. Un dispositivo que se desconecta y vuelve a conectarse retoma la actualización donde la dejó, sin que el servidor tenga que volver a enviar comandos.

En el caso de campañas de actualización para toda la flota, esto significa que no tienes que gestionar una cola de comandos MDM pendientes. Declaras la intención una sola vez y los dispositivos se adaptan a los requisitos según sus propios plazos, dentro de los parámetros que hayas establecido.

DDM en contexto: proveedores de identidad e integración de SSO

Un ámbito en el que el sistema de predicados de DDM ofrece un valor empresarial significativo es la configuración condicional basada en el contexto de identidad. El alcance tradicional del MDM es relativamente general: se asignan perfiles a grupos de dispositivos o a grupos de usuarios. Las activaciones de DDM pueden evaluar condiciones más detalladas.

Ejemplos prácticos para entornos empresariales:

• Aplicar requisitos de código de acceso más estrictos en los dispositivos en los que la cuenta de usuario tenga acceso privilegiado, evaluados en función de los atributos del directorio
• Aplicar configuraciones de autenticación basadas en certificados únicamente cuando exista un activo de certificado específico de la CA empresarial
• Activar declaraciones de configuración de VPN en función de si el dispositivo está conectado a un segmento de red específico

Estos comportamientos condicionales se ejecutan en el dispositivo. No requieren que el servidor reevalúe las asignaciones de ámbito cada vez que cambia una condición. El dispositivo realiza un seguimiento de la condición, reevalúa el predicado y ajusta su configuración de forma autónoma.

El enfoque de Iru respecto a la gestión declarativa de dispositivos

La implementación de DDM por parte de Iru es nativa, no adaptada a posteriori. Dado que Iru se ha desarrollado en torno a las API de gestión de Apple, las declaraciones DDM son una parte fundamental de cómo la plataforma proporciona las configuraciones, y no una función adicional superpuesta a un motor MDM heredado.

Para los equipos que gestionan miles de dispositivos Mac, iPhone y iPad, esto supone una diferencia práctica en algunas áreas concretas.

En primer lugar, la aplicación de actualizaciones de software a través de Iru utiliza declaraciones DDM para las versiones del sistema operativo compatibles, lo que significa que las campañas de actualización no generan una carga lineal en el servidor a medida que crece el tamaño de la flota. Con más de 10 000 dispositivos, la diferencia entre la gestión de actualizaciones basada en sondeos y la basada en DDM es cuantificable en términos de costes de infraestructura y tiempo del equipo de TI.

En segundo lugar, el motor de cumplimiento de Iru utiliza el canal de estado de DDM como fuente de datos para el estado de los dispositivos. Cuando un dispositivo notifica un cambio de configuración a través del canal de estado, esa señal se transmite a los paneles de control de cumplimiento casi en tiempo real. Los equipos de seguridad obtienen datos precisos sobre el estado de los dispositivos sin tener que esperar a las comprobaciones programadas.

En tercer lugar, el enfoque de Iru para el periodo de transición entre DDM y el MDM heredado consiste en ejecutar ambos protocolos en paralelo, utilizando DDM cuando Apple lo admite y los comandos heredados cuando aún son necesarios, sin que los equipos de TI tengan que gestionar esa distinción manualmente. Dado que Apple va a dejar de admitir los comandos heredados en iOS/macOS 26 y versiones posteriores, la arquitectura nativa de DDM de Iru implica que la transición requiere cambios de configuración, no cambios de plataforma.

Para los equipos que también estén planteándose una ruta de migración más amplia, merece la pena evaluar cuidadosamente las consideraciones de migración de MDM de Apple en torno a la compatibilidad con DDM a la hora de valorar cualquier plataforma MDM.

Qué deben hacer ahora los equipos de TI para prepararse para DDM

Si actualmente gestionas un parque de dispositivos Apple y aún no has empezado a incorporar DDM en tu estrategia de gestión, estos son los aspectos en los que debes centrarte.

Revisa la distribución de tus sistemas operativos. DDM requiere iOS 15 / macOS 12 o versiones posteriores. Los dispositivos que no alcancen ese umbral necesitan una vía de gestión independiente. Hazte una idea clara del número de dispositivos con los que trabajas y de sus versiones actuales de sistema operativo. Esto afecta directamente a tu proceso de gestión del inventario de hardware.

Identifica tus casos de uso de DDM de mayor prioridad. La aplicación de actualizaciones de software y la configuración continua de la seguridad son los mejores puntos de partida. Se trata de áreas en las que el modelo de aplicación autónoma de DDM aporta un valor inmediato y cuantificable.

Evalúa el grado de madurez de tu plataforma MDM en relación con DDM. Plantea preguntas específicas: ¿Utiliza la plataforma declaraciones DDM de forma nativa para las actualizaciones de software? ¿Se transmite el canal de estado a los paneles de cumplimiento en tiempo real? ¿Cómo gestiona la plataforma el periodo híbrido en el que algunos dispositivos admiten DDM y otros no? ¿Cómo se está preparando la plataforma para la obsolescencia de los comandos heredados de Apple en iOS/macOS 26?

Planifica tu lógica de predicados. El cambio a la lógica condicional del lado del dispositivo requiere replantearse el alcance de la configuración. En lugar de preguntarte «¿a qué grupo pertenece este dispositivo?», debes diseñar predicados que el dispositivo evalúe localmente. Asigna tu estructura de políticas existente a la lógica de declaraciones de DDM antes de empezar a desarrollar.

No esperes a que DDM tenga una cobertura total. Hoy en día, DDM y el MDM heredado coexisten. Empieza a utilizar DDM allí donde esté disponible y aporte valor. Esperar a que DDM alcance la paridad completa con el MDM heredado significa perderte las ventajas operativas disponibles ahora mismo.

La plataforma nativa de DDM de Iru está diseñada para facilitar esta transición a escala empresarial. Si quieres ver cómo funcionan en la práctica las configuraciones declarativas para un parque de dispositivos de tu tamaño, ponte en contacto con Iru.