Microsoft Intune: qué es, licencias e implantación

Cómo convertir una necesidad de seguridad en una política de Intune

Una implantación de Microsoft Intune funciona mejor cuando cada política responde a una necesidad observable. Si el problema son portátiles sin cifrar, hay que definir cómo se configura el cifrado, cómo se comprueba su estado y qué ocurre cuando un equipo no cumple. Crear una política con el nombre correcto no demuestra que los dispositivos la hayan recibido ni que el usuario disponga de una vía para solucionar una incidencia.

En un ejemplo ilustrativo, una empresa quiere exigir dispositivos conformes para acceder a SharePoint. Primero inscribe un grupo representativo, distribuye la configuración y revisa los motivos de incumplimiento. Después prueba el acceso condicional con alcance controlado. Si se activa el bloqueo cuando todavía hay equipos pendientes de inscripción, el resultado será una interrupción del trabajo, aunque la condición de seguridad esté bien formulada.

Por eso la documentación de una política debe incluir propósito, plataformas compatibles, grupos de asignación, exclusiones justificadas, método de comprobación y procedimiento de recuperación. También necesita un propietario que revise cambios y excepciones. Un equipo que no recibe la configuración puede tener un problema de conexión, inscripción o aplicabilidad; modificar la política antes de identificar la causa puede extender el problema a dispositivos que ya funcionaban.

El portátil corporativo y el móvil personal requieren decisiones distintas

En un portátil de empresa puede ser razonable administrar configuración, aplicaciones y actualizaciones del dispositivo completo. En un móvil personal hay que valorar si basta con proteger las aplicaciones y los datos corporativos en los escenarios compatibles. La elección depende de la plataforma, de las aplicaciones utilizadas y del control requerido; no debe hacerse únicamente por comodidad del equipo de administración.

Para un usuario que consulta Outlook y Teams en su teléfono, el piloto debe comprobar cómo se inicia sesión, dónde se puede guardar un adjunto y qué sucede cuando se retira el acceso corporativo. Esas pruebas explican con claridad el efecto de una política de protección de aplicaciones. También permiten distinguir una restricción prevista de un fallo que impide utilizar una aplicación necesaria para el trabajo.

La aceptación de Intune debe medir cobertura y funcionamiento. Además del porcentaje de dispositivos inscritos, interesa conocer cuántos reciben las aplicaciones obligatorias, cuánto tardan en resolver un incumplimiento y qué incidencias llegan a soporte. Un despliegue que presenta buenas cifras de inscripción pero mantiene equipos sin actualizar o usuarios bloqueados todavía necesita ajustes operativos.

Qué es Microsoft Intune

Microsoft Intune es el servicio de Microsoft para la administración unificada de endpoints desde la nube. Forma parte de la familia Microsoft Intune y permite administrar dispositivos y aplicaciones utilizando políticas centralizadas. Desde Intune podemos trabajar sobre diferentes áreas:

Intune no es únicamente un MDM para móviles. El nombre histórico de Mobile Device Management puede llevar a confusión. Actualmente Intune se utiliza habitualmente para gestionar: portátiles Windows, Macs, iPhone, iPad, Android, determinados endpoints Linux, dispositivos compartidos y otros escenarios compatibles. Tampoco sustituye automáticamente todas las herramientas existentes. Una empresa que ya utiliza Configuration Manager, una solución MDM especializada o herramientas concretas de gestión de Apple puede realizar una transición progresiva.

El objetivo debería ser analizar qué workloads merece la pena modernizar, no retirar tecnología únicamente porque Intune exista. Referencia oficial: Microsoft – What is Microsoft Intune?.

Qué problemas resuelve realmente Intune

La forma más útil de entender Intune es traducir funciones técnicas a problemas cotidianos.

Qué modelo de Intune utilizar según el tipo de dispositivo

Uno de los errores más frecuentes es aplicar el mismo modelo a todo. Un portátil corporativo utilizado por un empleado de Finanzas no necesita necesariamente la misma gestión que un iPhone personal, una tablet de almacén o un terminal Android compartido.

La propiedad importa. Antes de decidir la política debemos saber si el dispositivo es: corporativo, personal, compartido o dedicado. Esto afecta a: qué podemos administrar, qué esperamos que el usuario acepte, qué podemos borrar, qué datos personales debemos respetar y qué políticas de acceso son razonables.

MDM, MAM y BYOD: tres conceptos que conviene separar

MDM y MAM responden a necesidades de control diferentes. Con la administración de dispositivos, o MDM, el equipo se inscribe en Intune y recibe configuraciones compatibles con su plataforma. Esto permite, por ejemplo, distribuir aplicaciones, configurar certificados o evaluar requisitos de cumplimiento. El alcance real depende del sistema operativo y del método de inscripción, por lo que no conviene prometer el mismo control sobre todos los equipos.

La administración de aplicaciones, o MAM, se centra en las aplicaciones compatibles y en la información corporativa que manejan. En determinados escenarios permite proteger esos datos sin administrar por completo el dispositivo. Una política puede regular el acceso a una aplicación, las ubicaciones donde se guardan sus documentos o el intercambio de información con aplicaciones personales. Esos controles deben probarse con la versión y el sistema que utilizarán los empleados.

BYOD describe la propiedad del dispositivo: el trabajador utiliza un equipo personal para acceder a servicios de la empresa. No es una tecnología de protección ni determina por sí solo el modelo que debe aplicarse. Antes de elegir entre inscripción, protección de aplicaciones u otra alternativa, se necesita conocer qué datos se consultarán y qué acciones requiere el trabajo. La decisión debe cubrir también la retirada del acceso cuando cambia la relación con la organización.

En un escenario de teléfono personal, el piloto puede empezar con Outlook y un documento corporativo. Se comprueba si el usuario puede abrirlo, copiar contenido, guardarlo o enviarlo a otra aplicación, de acuerdo con la política prevista. Después se ensaya la retirada de los datos administrados en un dispositivo de prueba. Ese recorrido permite explicar el efecto del control y documentar qué información personal queda fuera de su alcance.

En un equipo corporativo compartido, en cambio, la prioridad puede ser disponer de aplicaciones homogéneas y evitar que el siguiente usuario encuentre una sesión anterior abierta. El diseño de inscripción y uso será diferente al de un portátil asignado a una sola persona. La elección debe quedar acompañada de instrucciones de soporte, recuperación y comunicación: una configuración segura que el usuario no entiende genera incidencias y facilita la aparición de soluciones improvisadas.

Documentación de referencia: Microsoft – App Protection Policies; Microsoft – MAM without device enrollment.

Qué plataformas soporta Microsoft Intune

La documentación actual de Microsoft contempla Intune para: Android, iOS/iPadOS, Linux, macOS, Windows y Chrome OS. Eso no significa que todas las funciones estén disponibles en todas las plataformas.

Revisar siempre versión mínima. Microsoft actualiza periódicamente las versiones de sistema operativo admitidas. No deberíamos diseñar una política basándonos únicamente en: “tenemos iOS” sino en: modelo, versión, enrollment method, ownership. Windows 10 en 2026. Windows 10 alcanzó el final de soporte general el 14 de octubre de 2025. Microsoft todavía puede permitir determinados escenarios de inscripción o funciones en Intune, pero para nuevos proyectos empresariales deberíamos partir de una estrategia Windows 11 salvo que exista una razón técnica y un modelo de soporte específico para mantener Windows 10.

Referencia oficial: Microsoft – Supported operating systems and browsers.

Cómo encaja Intune dentro de Microsoft 365

Intune obtiene mucho más valor cuando no se utiliza de forma aislada.

Ejemplo completo. Podemos tener una política donde: Intune comprueba que el portátil está cifrado, Defender indica que el endpoint no presenta riesgo alto, Intune marca el equipo como compliant, Conditional Access recibe esa señal y Microsoft Entra permite acceder a SharePoint. Esto es mucho más potente que pensar simplemente: “el ordenador está registrado en Intune”.

Inscripción de dispositivos: no existe un único método

El enrollment determina cómo entra un dispositivo en administración. La elección depende de: plataforma, propiedad, usuario, forma de entrega, nivel de control.

Enrollment restrictions. No deberíamos permitir que cualquier usuario inscriba cualquier tipo de dispositivo simplemente porque Intune lo permite. Podemos restringir: plataformas, versiones, propiedad, número de dispositivos y determinados métodos de enrollment. Corporate identifiers. En algunos escenarios podemos utilizar identificadores corporativos para ayudar a distinguir dispositivos propiedad de la empresa frente a dispositivos personales. Referencia oficial: Microsoft – Device enrollment.

Configuración, compliance y Conditional Access: no son lo mismo

Es uno de los conceptos más importantes para administrar Intune correctamente. Configuration Policy. Define cómo queremos configurar el dispositivo. Por ejemplo: “Activa BitLocker”. Compliance Policy. Evalúa si el dispositivo cumple un requisito. Por ejemplo: “El disco debe estar cifrado”. Conditional Access. Decide qué ocurre si el requisito no se cumple. Por ejemplo: “Si el equipo no es compliant, no permitas acceder a SharePoint”.

Ejemplos de compliance. Según plataforma pueden evaluarse requisitos como: versión mínima del sistema operativo, cifrado, contraseña/PIN, Secure Boot, firewall, antivirus, integridad del dispositivo, jailbreak/root y nivel de riesgo procedente de Defender. No activar bloqueo antes de tener cobertura. Si hoy solo el 40 % del parque está correctamente inscrito y mañana activamos: All Users, Require Compliant Device podemos transformar una mejora de seguridad en una incidencia masiva.

Secuencia recomendada. inventario → enroll → configure → measure → remediate → enforce.

Microsoft Defender for Endpoint, Intune

Un dispositivo puede cumplir todas nuestras configuraciones y aun así estar comprometido. Por eso Intune puede integrarse con Microsoft Defender for Endpoint. Device risk. Defender puede calcular un nivel de riesgo para el endpoint. Ese riesgo puede convertirse en una condición de compliance. Ejemplo. Podemos establecer: Maximum allowed device threat level = Medium. Si Defender clasifica el endpoint como High Risk: Intune puede marcarlo como non-compliant, Conditional Access puede limitar su acceso y El equipo de seguridad puede investigar y remediar.

Importante: no bloquear sin proceso de recuperación. La policy no debería terminar en: “usuario bloqueado”. También necesitamos definir: alerta → análisis → remediación → reevaluación → recuperación del acceso. Referencia oficial: Microsoft – Defender for Endpoint with Intune.

Gestión de aplicaciones con Microsoft Intune

La gestión de aplicaciones suele convertirse en una de las partes más operativas de Intune. Podemos desplegar. Según plataforma y escenario: Microsoft 365 Apps, Microsoft Store Apps, Win32 Apps, Line-of-Business Apps, aplicaciones móviles, PKG/DMG en macOS según escenario, web apps y aplicaciones desde Enterprise App Catalog. Required vs Available. No todo el software debe instalarse obligatoriamente.

Company Portal. Puede funcionar como catálogo empresarial donde los usuarios instalan software aprobado sin necesidad de tener privilegios administrativos. Dependencias y detection rules. En aplicaciones Win32 debemos diseñar correctamente: comando de instalación, desinstalación, detection rule, requirements, dependencias, supersedence cuando corresponda y restart behaviour. Una app marcada como “Installed” no garantiza que funcione. El reporting técnico debe complementarse con una prueba funcional durante el piloto.

Windows Autopilot

Windows Autopilot permite preparar dispositivos Windows para su incorporación a la organización utilizando la instalación OEM de Windows en lugar de mantener necesariamente imágenes corporativas tradicionales. Escenario típico. La empresa compra un portátil y el proveedor registra su hardware en Autopilot. El ordenador puede enviarse directamente al empleado. Al encenderlo: Windows detecta que pertenece a la organización, Se aplica la experiencia Autopilot, El usuario se autentica, El equipo se une a Microsoft Entra ID, Se inscribe en Intune y Recibe aplicaciones y políticas.

Esto reduce mucho la intervención manual. Especialmente para: empleados remotos, renovaciones de hardware, empresas con varias sedes y proveedores que envían directamente al usuario. Registro. El Autopilot clásico requiere que el dispositivo esté registrado en el servicio Autopilot. Esto normalmente implica asociar su identidad hardware con el tenant. Idealmente lo realiza el fabricante o distribuidor. Esto evita tener que abrir cada portátil únicamente para capturar el hardware hash.

Escenarios avanzados. Windows Autopilot clásico continúa siendo relevante porque dispone de escenarios como: User-driven, Pre-provisioning, Self-deploying, Existing devices, Autopilot Reset y Microsoft Entra Hybrid Join en escenarios compatibles. Referencia oficial: Microsoft – Windows Autopilot overview.

Windows Autopilot Device Preparation: la nueva arquitectura

Microsoft dispone además de Windows Autopilot Device Preparation. No es simplemente un nuevo nombre para Autopilot. Microsoft lo describe como una rearquitectura de la experiencia de aprovisionamiento. Objetivo. Simplificar el despliegue y mejorar: velocidad, consistencia, monitorización, troubleshooting y experiencia del administrador. No necesita prestaging tradicional del dispositivo. Una diferencia interesante es que las políticas pueden asignarse al grupo de usuarios correspondiente.

Cuando un usuario incluido inicia OOBE en un dispositivo compatible, comienza el proceso de Device Preparation. Microsoft Entra Join únicamente. Actualmente Windows Autopilot Device Preparation no admite Microsoft Entra Hybrid Join. Esto encaja con una estrategia cloud-native, pero puede ser una limitación para organizaciones que todavía necesitan join híbrido. Windows 11. Device Preparation está orientado a Windows 11 compatible. Mejor reporting.

Microsoft destaca una monitorización cercana al tiempo real y más información para diagnosticar despliegues. LOB, Win32 durante el mismo despliegue. La arquitectura serializada de Device Preparation permite manejar determinados tipos de aplicaciones con mayor consistencia durante el aprovisionamiento. Menos aplicaciones durante OOBE puede ser una ventaja. Microsoft limita deliberadamente el número de aplicaciones y scripts procesados durante la fase inicial para mejorar la estabilidad.

Esto refuerza una recomendación que también debería aplicarse al Autopilot tradicional: no intentar instalar todo el software de la empresa antes de que el usuario pueda llegar al escritorio. Referencia oficial: Microsoft – Windows Autopilot Device Preparation.

Windows Autopilot vs Windows Autopilot Device Preparation

¿Cuál utilizar?. No existe una respuesta universal. Para una organización completamente cloud-native con equipos Windows 11 y un escenario sencillo user-driven, Device Preparation merece una evaluación seria. Si necesitamos pre-provisioning, self-deploying, escenarios de dispositivos existentes o determinadas arquitecturas híbridas, Autopilot clásico continúa siendo relevante. Referencia oficial: Microsoft – Compare Autopilot solutions.

Apple Business Manager y Automated Device Enrollment

Para dispositivos Apple corporativos, Intune se integra con Apple Business Manager. Automated Device Enrollment, o ADE, permite incorporar dispositivos Apple de forma más controlada. Casos habituales: iPhone corporativo, iPad corporativo y Mac corporativo. Ventajas. Con una integración adecuada podemos: automatizar enrollment, aplicar perfiles durante configuración inicial, supervisar dispositivos corporativos cuando corresponda, reducir intervención del usuario y establecer una relación más fuerte entre dispositivo y organización.

No olvidar los tokens y certificados Apple. Una implantación de Apple con Intune tiene elementos operativos que deben renovarse periódicamente. Deben tener: owner, documentación, proceso de renovación. Referencias oficiales:

• Microsoft – ADE for iOS/iPadOS
• Microsoft – ADE for macOS

Android Enterprise

Android Enterprise ofrece diferentes modelos dependiendo de quién sea propietario del dispositivo y cómo se utilice.

Android Device Administrator ya no es el modelo a utilizar. El antiguo modelo Device Administrator está obsoleto para dispositivos con Google Mobile Services. En nuevos despliegues debemos utilizar opciones modernas de Android Enterprise o App Protection según el escenario. Work Profile es especialmente útil en BYOD. Permite mantener: perfil personal, perfil corporativo separados dentro del mismo dispositivo. Dedicated Devices. Son especialmente apropiados para: lectores de almacén, terminales de tienda, kioscos, dispositivos de una sola función y equipos compartidos.

Referencia oficial: Microsoft – Android enrollment guide.

Windows Update y Windows Autopatch

Administrar endpoints no termina cuando el dispositivo está configurado. También hay que mantenerlo actualizado. Windows Update mediante Intune. Intune permite administrar distintas políticas de actualización, incluyendo: Update Rings, Feature Updates, Quality Updates y Driver Updates en escenarios compatibles. Anillos de actualización. No todos los dispositivos tienen por qué actualizarse al mismo tiempo. Podemos definir, por ejemplo:

Windows Autopatch. Windows Autopatch automatiza una parte importante de la gestión del ciclo de actualización. Microsoft lo integra actualmente en la experiencia de Intune. Objetivo. Reducir el trabajo manual necesario para mantener actualizados dispositivos compatibles y conseguir un despliegue progresivo y monitorizado. No elimina la operación. Seguimos necesitando: compatibilidad de aplicaciones, gestión de excepciones, monitorización, respuesta ante fallos y ventanas operativas cuando correspondan.

Licenciamiento. Windows Autopatch está disponible con determinados planes como Microsoft 365 Business Premium, Microsoft 365/Windows Enterprise compatibles y otras licencias elegibles. Debe verificarse el entitlement concreto del tenant. Referencia oficial: Microsoft – Windows Autopatch.

Hotpatch: actualizar seguridad con menos reinicios

Hotpatch permite instalar determinadas actualizaciones de seguridad sobre dispositivos Windows compatibles sin requerir reinicio en cada ciclo mensual. No significa “nunca reiniciar”. Microsoft sigue utilizando actualizaciones baseline periódicas que requieren reinicio. Por qué es interesante. En determinados parques empresariales puede mejorar: velocidad de parcheo, experiencia de usuario, cumplimiento y reducción de reinicios mensuales. Requisitos. Hotpatch requiere combinaciones específicas de: Windows 11, versión/build compatible, licencia compatible, administración mediante Intune.

No deberíamos asumir que todos los Windows 11 pueden utilizarlo automáticamente. Referencia oficial: Microsoft – Hotpatch updates.

Endpoint Privilege Management: reducir administradores locales

Muchos entornos todavía tienen un problema histórico: el usuario es administrador local porque ocasionalmente necesita instalar o actualizar algo. Esto convierte una excepción puntual en privilegio permanente. Endpoint Privilege Management. Microsoft Intune Endpoint Privilege Management permite mantener al usuario como estándar y autorizar elevaciones específicas de forma controlada. Ejemplos.

Objetivo: least privilege. El usuario no debería disponer permanentemente de más privilegios que los que necesita para realizar su trabajo. Antes de retirar admin local. Inventariar: qué aplicaciones requieren elevación, qué tareas realiza soporte, qué software se instala manualmente, qué drivers se actualizan y qué equipos tienen necesidades especiales. No crear una regla que permita elevar cualquier ejecutable. Eso reproduciría prácticamente el problema que intentábamos resolver.

Referencia oficial: Microsoft – Endpoint Privilege Management.

Remote Help: soporte remoto integrado con Intune

Remote Help proporciona asistencia remota basada en cloud integrada con Microsoft Intune. Qué aporta frente a una herramienta genérica. Está integrada con la identidad corporativa y puede utilizar: Microsoft Entra authentication, RBAC, auditoría, información del dispositivo, controles de acceso y sesiones de asistencia identificadas. Plataformas. La documentación actual contempla escenarios en: Windows, macOS, Android y aplicación web con diferentes requisitos y capacidades.

No permite soporte entre tenants. Una limitación especialmente importante para proveedores de TI es que: Remote Help no permite establecer una sesión desde un tenant hacia otro tenant distinto. Por tanto, no debemos asumir que un equipo de soporte ubicado en el tenant de un MSP puede controlar directamente los dispositivos de todos sus clientes utilizando una única instancia de Remote Help.

Dispositivos no inscritos. Microsoft permite determinados escenarios de Remote Help con endpoints no inscritos si la organización habilita esa posibilidad y se cumplen los requisitos correspondientes. Esto amplía los casos de uso, pero no convierte Remote Help en una herramienta universal para cualquier dispositivo. Android. El soporte Android tiene requisitos específicos y está especialmente orientado a determinados dispositivos Android Enterprise dedicados compatibles.

Referencia oficial: Microsoft – Plan for Remote Help.

Endpoint Analytics y Advanced Analytics

La administración moderna no debería limitarse a preguntar: “¿el dispositivo cumple la política?” También interesa conocer: ¿funciona bien para el usuario? Endpoint Analytics. Proporciona información sobre experiencia y rendimiento de dispositivos. Advanced Analytics. Añade capacidades más avanzadas para investigar problemas y comprender la salud del parque. Ejemplos: battery health, resource performance, anomalies, device timeline, device query e información para troubleshooting.

Renovación de hardware basada en datos. En lugar de renovar equipos únicamente porque: “tienen cuatro años” podemos incorporar información sobre: batería, memoria, rendimiento, experiencia, incidencias. Referencia oficial: Microsoft – Advanced Analytics.

Microsoft Cloud PKI

Microsoft Cloud PKI proporciona una infraestructura de certificados gestionada desde cloud e integrada con Intune. Casos de uso. Puede utilizarse para emitir certificados destinados a escenarios como: Wi-Fi empresarial, VPN, autenticación de dispositivos, certificados de usuario y determinados escenarios de autenticación empresarial. CA gestionada por Microsoft. Cloud PKI permite crear autoridades de certificación y administrar el ciclo de vida de certificados sin mantener necesariamente toda una infraestructura Microsoft AD CS on-premises.

No significa que podamos retirar AD CS sin assessment. Una PKI existente puede estar utilizada por: Wi-Fi, VPN, servidores, equipos industriales, smartcards, aplicaciones, web servers, firma y certificados internos. Cloud PKI debe evaluarse contra los usos reales antes de plantear una sustitución. Referencia oficial: Microsoft – Cloud PKI.

Enterprise Application Management

El empaquetado y mantenimiento de aplicaciones Win32 puede consumir mucho tiempo en un equipo de endpoint management. Enterprise Application Management proporciona acceso a un catálogo empresarial mantenido por Microsoft para determinadas aplicaciones. Enterprise App Catalog. Podemos seleccionar aplicaciones soportadas desde un catálogo y aprovechar: contenido alojado, comandos de instalación preparados, requisitos, detection rules e información de la aplicación. No elimina todas las aplicaciones personalizadas.

Seguiremos necesitando empaquetar: software interno, aplicaciones LOB, configuraciones específicas, software que no se encuentre en catálogo. Valor operativo. Su principal ventaja es reducir el tiempo invertido en mantener paquetes de aplicaciones comunes. Referencia oficial: Microsoft – Enterprise Application Management.

Copilot en Microsoft Intune

Microsoft también ha integrado capacidades de Copilot en la experiencia de administración de Intune. Puede ayudar al administrador a: comprender políticas y configuraciones, analizar determinados problemas de dispositivos, interpretar datos del endpoint, acelerar tareas de troubleshooting y obtener contexto sobre postura y configuración. Licenciamiento. Copilot en Intune está vinculado a Microsoft Security Copilot. No debemos asumir que disponer de una licencia Intune Plan 1 activa automáticamente estas capacidades.

Copilot no sustituye el diseño de políticas. Puede ayudar al administrador a entender información y trabajar más rápido, pero las decisiones sobre: scope, seguridad, excepciones, impacto siguen necesitando contexto empresarial. Referencia oficial: Microsoft – Copilot in Intune.

¿Intune sustituye a Microsoft Configuration Manager?

No necesariamente de un día para otro. Microsoft mantiene escenarios de cloud attach y co-management para organizaciones que ya utilizan Configuration Manager. Co-management. Un dispositivo Windows puede estar administrado simultáneamente por: Configuration Manager, Microsoft Intune. Se decide qué plataforma administra cada workload. Workloads. Microsoft documenta, entre otros: Compliance Policies, Windows Update Policies, Resource Access, Endpoint Protection, Device Configuration, Office Click-to-Run y Client Apps.

Podemos moverlos progresivamente. Por ejemplo:

No hace falta migrar todo en la misma semana. Co-management existe precisamente para permitir una transición controlada. Cloud Attach y Tenant Attach. También podemos obtener visibilidad y determinadas funciones cloud sin trasladar inmediatamente todos los workloads a Intune. Referencia oficial: Microsoft – Co-management.

Licencias de Microsoft Intune en 2026

El licenciamiento merece una sección específica porque ha cambiado y porque una implantación puede diseñarse incorrectamente si asumimos que todas las capacidades visibles en el portal están incluidas. Los tres planes de Intune.

Intune Plan 1. Es la base para: MDM, MAM, configuration, compliance, applications, device enrollment y endpoint management. Plan 2. Microsoft lo utiliza como capa adicional de administración avanzada. La documentación actual identifica en este nivel capacidades como: Remote Help y Advanced Analytics. Intune Suite. Agrupa Plan 2 junto con varias capacidades avanzadas adicionales, entre ellas —según edición y disponibilidad—: Endpoint Privilege Management, Microsoft Cloud PKI, Enterprise Application Management, Remote Help, Advanced Analytics y otras capacidades avanzadas documentadas por Microsoft.

Cambio muy importante desde julio de 2026

Microsoft ha distribuido parte de estas capacidades avanzadas directamente dentro de determinados paquetes Microsoft 365.

Business Premium. Microsoft 365 Business Premium incluye Intune Plan 1, pero no debemos extrapolar automáticamente las nuevas incorporaciones de E3/E5 a Business Premium. Las funcionalidades avanzadas adicionales deben revisarse según el contrato y add-ons disponibles. Microsoft 365 E3 ya no debe describirse como “solo Intune Plan 1”. Esta es una diferencia relevante respecto a muchas comparativas anteriores a julio de 2026.

Licenciamiento por usuario. La mayoría de capacidades están orientadas a licenciamiento de usuario, aunque existen escenarios de dispositivos compartidos o especiales con opciones diferentes. Remote Help. Las personas que participan en Remote Help deben disponer del entitlement adecuado. No debemos asumir que una única licencia para el técnico habilita automáticamente a todos los usuarios. La tabla comercial no sustituye una revisión contractual.

Antes de presupuestar un proyecto conviene comprobar: SKU exacta, tipo de contrato, país, fecha, suite Microsoft 365, add-ons existentes y funcionalidad realmente necesaria. Referencias oficiales:

• Microsoft – Intune licensing
• Microsoft – Intune advanced capabilities
• Microsoft – Intune plans and pricing

Cómo implementar Microsoft Intune paso a paso

Una implantación madura debería comenzar con diseño, no con políticas. Fase 1: inventario. Recopilar:

Fase 2: definir personas y escenarios. No diseñar únicamente grupos técnicos. Definir perfiles como: empleado con Windows corporativo, directivo con Windows, iPhone corporativo, usuario BYOD, empleado de tienda, administrador IT, desarrollador con Mac y terminal Android compartido. Fase 3: definir enrollment. Para cada perfil: quién lo registra, cómo, quién es owner, qué pasa al sustituirlo. Fase 4: grupos piloto. Crear grupos representativos.

No utilizar únicamente al departamento IT. Un piloto debería incluir usuarios reales que utilicen: VPN, ERP, impresoras, Teams, OneDrive, Outlook, aplicaciones LOB y móviles. Fase 5: baseline de configuración. Empezar por controles necesarios y comprensibles. En este caso se contemplan: BitLocker/FileVault, firewall, Defender Antivirus, password/PIN, screen lock, OneDrive, Microsoft Edge y Wi-Fi/VPN si aplica. Fase 6: compliance.

Definir qué características realmente determinan si un dispositivo es suficientemente seguro. No crear criterios que nadie vaya a remediar. Fase 7: aplicaciones. Clasificarlas:

Fase 8: Conditional Access en Report-only. Antes de bloquear dispositivos no conformes, comprobar: qué usuarios se verían afectados, qué dispositivos fallarían, qué aplicaciones dependen de excepciones y qué dispositivos personales necesitan otra estrategia. Fase 9: Defender. Integrar device risk y definir proceso de remediación. Fase 10: updates. Diseñar: pilot rings, production rings, feature updates, quality updates, exceptions. Fase 11: capacidades avanzadas.

Una vez estabilizada la base podemos valorar: EPM, Remote Help, Advanced Analytics, Cloud PKI y Enterprise App Management. Fase 12: enforcement. Activar progresivamente: Require compliant device, app protection, risk-based controls. Fase 13: documentación y soporte. Preparar: procedimientos de alta, baja, equipo perdido, equipo sustituido, device wipe, retire, non-compliance, Autopilot failure, aplicación que falla, excepción y BYOD.

Roadmap de 90 días para Microsoft Intune

Días 1-30: discovery y base.

Días 31-60: expandir.

Días 61-90: enforcement y mejora.

Intune no termina cuando acaba el proyecto

Una plataforma de endpoint management requiere operación continua. Semanalmente. Antes del cambio deben revisarse: errores de enrollment, aplicaciones fallidas, dispositivos non-compliant, problemas de actualización y alertas relevantes. Mensualmente. Antes del cambio deben revisarse: versiones de sistema operativo, hardware obsoleto, grupos y asignaciones, políticas conflictivas, excepciones, admins locales y estado de apps. Trimestralmente. Antes del cambio deben revisarse: baseline, supported OS, licenciamiento, nuevas funcionalidades, métricas, procesos de soporte, BYOD y Conditional Access.

Apple tokens y certificados. Las renovaciones operativas deben estar calendarizadas. Depender de que una persona recuerde un correo de renovación no es un proceso de gestión.

Qué métricas de Intune merece la pena seguir

Errores frecuentes al implementar Microsoft Intune

Checklist para implementar Microsoft Intune

Preguntas frecuentes sobre Microsoft Intune

¿Intune puede proteger un móvil personal sin administrar todo el teléfono?

En escenarios compatibles, las políticas de protección de aplicaciones permiten controlar datos corporativos sin inscribir completamente el dispositivo. La disponibilidad depende de plataforma, aplicación y configuración. Antes de elegir este modelo se deben probar las acciones necesarias para el trabajo y explicar al empleado qué controla la empresa y cómo se retirará el acceso corporativo.

¿Una política de cumplimiento bloquea directamente el acceso?

Intune evalúa el estado de cumplimiento del dispositivo. Microsoft Entra Conditional Access puede utilizar ese estado para decidir el acceso a los recursos definidos. Son decisiones relacionadas, pero distintas. El despliegue debe comprobar primero que los equipos reciben las políticas y pueden corregir los incumplimientos, antes de extender condiciones que bloqueen el trabajo.

¿Qué licencia hace falta para implantar Intune?

Hay que revisar el plan de Intune disponible y las funciones concretas del proyecto. Algunas suites incluyen capacidades base y otras añaden funcionalidades avanzadas, pero no debe asumirse que todo está incluido por disponer de Microsoft 365. La comprobación se realiza sobre la suscripción contratada, los usuarios o dispositivos afectados y los requisitos de cada función.

¿Conviene incorporar todos los dispositivos de una sola vez?

Un despliegue por grupos permite comprobar inscripción, aplicaciones, configuración, cumplimiento y soporte antes de ampliar el alcance. El piloto debe representar los sistemas operativos y los modelos de uso reales, incluidos dispositivos compartidos o personales cuando corresponda. Los resultados se utilizan para ajustar las políticas y preparar instrucciones de recuperación para los usuarios.

Recomendaciones finales: Intune funciona mejor cuando deja de verse como una herramienta para “gestionar ordenadores”

Microsoft Intune puede convertirse en una de las piezas centrales de una estrategia moderna de puesto de trabajo, pero su valor no aparece simplemente por inscribir dispositivos. Una implantación útil conecta varias decisiones. Primero tenemos que determinar qué tipo de endpoint tenemos delante. Un portátil corporativo Windows probablemente justifique administración completa. Un teléfono personal puede necesitar únicamente protección de aplicaciones. Un dispositivo Android de almacén puede necesitar un modelo Dedicated. Un parque existente de Configuration Manager puede beneficiarse de co-management en lugar de una migración brusca.

Después diseñamos cómo se incorpora ese endpoint. Windows Autopilot continúa siendo una tecnología muy relevante, pero en 2026 también debemos evaluar Windows Autopilot Device Preparation. La nueva arquitectura simplifica varios escenarios cloud-native y mejora la información de despliegue, mientras el Autopilot clásico sigue ofreciendo capacidades que Device Preparation todavía no cubre. Una vez administrado el endpoint, necesitamos distinguir entre tres capas: configuration, compliance y access.

Intune puede configurar el dispositivo, puede evaluar si cumple los requisitos y Microsoft Entra Conditional Access puede decidir qué recursos están disponibles en función de ese estado. La integración con Defender añade además riesgo real del endpoint a la ecuación. Esto permite pasar de: “este portátil pertenece a la empresa” a: “este portátil pertenece a la empresa, está cifrado, actualizado, correctamente configurado y no tiene un nivel de riesgo que impida acceder a nuestros datos”.

La misma evolución se aplica a otras áreas. Endpoint Privilege Management puede reducir la necesidad de administradores locales permanentes. Remote Help puede ofrecer soporte remoto con identidad y auditoría. Advanced Analytics ayuda a comprender la experiencia real del endpoint. Cloud PKI permite abordar determinados escenarios de certificados desde cloud. Enterprise Application Management puede reducir trabajo operativo sobre aplicaciones comunes. El licenciamiento también ha cambiado de forma importante.

Desde julio de 2026, Microsoft 365 E3 incorpora capacidades avanzadas de Intune como Plan 2, Remote Help y Advanced Analytics, mientras Microsoft 365 E5 amplía el conjunto con EPM, Cloud PKI y Enterprise Application Management. Por eso una revisión de licencias debe realizarse antes de comprar add-ons o diseñar el proyecto. Y finalmente está la operación. Intune no es una configuración que se termina y se olvida.

Los sistemas operativos cambian, aparecen nuevas aplicaciones, se renueva hardware, Microsoft introduce nuevas capacidades, cambian los requisitos de seguridad y las excepciones tienden a acumularse. La pregunta útil no debería ser: “¿tenemos Intune?” sino: “¿sabemos qué dispositivos tenemos, están administrados con el modelo adecuado, cumplen nuestras políticas, podemos controlar el acceso y tenemos un proceso operativo para mantenerlos seguros sin impedir que los usuarios trabajen?”

Cuando la respuesta es afirmativa, Intune deja de ser simplemente un MDM y pasa a formar parte de una arquitectura real de gestión y seguridad del puesto de trabajo.

Documentación oficial recomendada

Microsoft Intune.

• Microsoft – What is Microsoft Intune?
• Microsoft – Planning guide to move to Intune
• Microsoft – Supported operating systems

Licencias.

• Microsoft – Intune licensing
• Microsoft – Advanced Intune capabilities
• Microsoft – Intune plans and pricing

MDM, MAM y BYOD.

• Microsoft – App Protection Policies
• Microsoft – MAM without enrollment
• Microsoft – Device enrollment

Windows Autopilot.

• Microsoft – Windows Autopilot documentation
• Microsoft – Windows Autopilot overview
• Microsoft – Autopilot registration
• Microsoft – Windows Autopilot Device Preparation
• Microsoft – Compare Autopilot and Device Preparation

Apple y Android.

• Microsoft – Apple ADE for iOS/iPadOS
• Microsoft – Apple ADE for macOS
• Microsoft – Android enrollment guide

Compliance, Conditional Access y Defender.

• Microsoft – Device Compliance
• Microsoft – Conditional Access and Intune
• Microsoft – Defender for Endpoint integration

Windows Update y Autopatch.

• Microsoft – Windows Update Management
• Microsoft – Windows Autopatch
• Microsoft – Windows Autopatch FAQ

Capacidades avanzadas.

• Microsoft – Endpoint Privilege Management
• Microsoft – Remote Help
• Microsoft – Advanced Analytics
• Microsoft – Microsoft Cloud PKI
• Microsoft – Enterprise Application Management

Configuration Manager.

• Microsoft – Co-management
• Microsoft – Cloud attach