La respuesta corta
Cuando el equipo de seguridad dice "la app tiene que estar gestionada", casi nunca está pidiendo MDM. Está pidiendo MAM: políticas de protección de aplicaciones que se aplican al dato corporativo dentro de tu app, no al dispositivo entero.
La diferencia es la que decide si el proyecto sale adelante. MDM exige que el usuario entregue el control de su teléfono a la empresa, y en dispositivos personales eso lo rechaza mucha gente. MAM permite aplicar la política directamente a la app, sin canal de gestión de dispositivo — y eso es lo que hace viable el BYOD.
Para tu app, la consecuencia es concreta: hay que integrar el Intune App SDK (o pasar el binario por las herramientas de app wrapping). Sin eso, Intune no la reconoce como app gestionada y ninguna política se le puede aplicar.
MDM y MAM no son lo mismo
| MDM (gestión de dispositivo) | MAM / App Protection Policies | |
|---|---|---|
| Qué controla | El dispositivo completo | El dato corporativo dentro de la app |
| Qué exige al usuario | Inscribir su teléfono | Nada, en el caso sin inscripción |
| Encaja en | Dispositivo de empresa | BYOD, y también corporativo |
| Qué toca en tu app | Poco o nada | Integrar el SDK |
En la práctica conviven: el mismo cliente puede tener flota corporativa inscrita y personal con dispositivo propio, y tu app tiene que funcionar en las dos.
Lo que una política puede imponer sobre tu app
Esto es lo que el administrador de IT va a poder activar desde su consola una vez integres el SDK. Conviene leerlo como lista de requisitos de producto, porque cada línea cambia una pantalla:
- Bloquear la salida de ficheros. Puede desactivar que la app haga copia de seguridad de datos corporativos en la nube.
- Restringir el portapapeles. Impedir cortar o copiar desde tu app y pegar en una app personal no gestionada.
- Forzar cifrado en reposo de lo que la app guarde en el dispositivo.
- Borrado remoto selectivo del dato corporativo, sin tocar lo personal.
- Obligar a abrir los enlaces en Microsoft Edge, para que lo que se abre desde un entorno corporativo se quede dentro del perímetro de apps gestionadas.
- Exigir un PIN antes de acceder al dato corporativo, verificado contra Entra ID.
- Exigir inicio de sesión con cuenta corporativa para poder usar la app.
- Comprobar salud y cumplimiento del dispositivo: en iOS/iPadOS comprueba si está jailbroken; en Android, si está rooteado.
Ese último punto merece un aviso: si tu app ya trae su propia detección de jailbreak, hay que decidir cuál manda. Dos comprobaciones distintas dando veredictos distintos es un ticket de soporte recurrente.
Y el de Edge sorprende a los equipos de producto: significa que el usuario sale de tu app al pulsar un enlace, aunque tú tuvieras un visor interno cuidado. Si tu experiencia depende de abrir contenido web dentro de la app, esa política te la rompe. Mejor saberlo al diseñar.
Lo que tiene que hacer tu app: SDK o wrapping
Hay dos vías para que Intune reconozca la app:
- Intune App SDK, disponible para iOS y Android. Es la vía buena: se integra en el proyecto y permite además usar sus APIs para adaptar el comportamiento donde la política requiere participación de la app.
- App Wrapping Tools, que envuelven un binario ya compilado. Sirve cuando no controlas el código o no quieres tocarlo.
La documentación de Microsoft es explícita en algo que ayuda a estimar: el SDK busca minimizar los cambios de código, y la mayoría de funciones se habilitan sin cambiar el comportamiento de la app. La integración base es pequeña. Lo que cuesta son los dos casos siguientes.
Multi-identidad: el requisito que sí cambia la arquitectura
Multi-identity permite que en una misma app convivan una cuenta corporativa —sujeta a política— y una personal —fuera del control de IT—. Es el caso de las apps de Office: el mismo usuario con su correo de empresa y el suyo.
Para conseguirlo, la política se aplica solo a la identidad corporativa. Y eso, del lado del código, significa que cada dato que la app guarda tiene que saber a qué identidad pertenece. No es una casilla: es una decisión de modelo de datos, y retrofitearla en una app que asumía un único usuario es de las reescrituras caras.
Si el cliente va a tener usuarios con cuenta personal y corporativa en el mismo teléfono, esto entra en el alcance desde el primer sprint.
Borrado selectivo: necesita que tu app colabore
El borrado remoto es basado en identidad: borra los ficheros asociados a la identidad corporativa del usuario, no la app entera. Y por eso mismo requiere la participación de la app: es la app la que declara sobre qué identidad debe ejecutarse el borrado.
Si la app no lo declara, el comportamiento por defecto es borrar el directorio de la aplicación y avisar al usuario de que ha perdido el acceso. Traducido: si el equipo no implementa esta parte, el día que un empleado deja la empresa se le borra también lo personal que hubiera en la app. Es un incidente evitable con unas horas de trabajo.
Sin inscripción de dispositivo: el caso BYOD
La protección de aplicaciones sin inscripción está disponible con las App Wrapping Tools y con el Intune App SDK de iOS y de Android. Permite que Intune despliegue la política directamente sobre la app, sin depender de un canal de gestión del dispositivo.
Es la respuesta al problema real de adopción: la gente no quiere dar control global de su teléfono personal a la empresa. Si tu proyecto es una app para empleados que van a usar su propio móvil —comerciales, técnicos de campo, sanitarios— este es el escenario por defecto, no la excepción.
Lo que MAM no cubre
- No sustituye a la seguridad de tu app. Cifrado de transporte, gestión de tokens y almacenamiento seguro siguen siendo tuyos.
- No cubre a quien no use MSAL ni el SDK. El perímetro son las apps gestionadas; lo que salga de ahí, sale.
- No es lo mismo que Acceso Condicional. Van juntos y se confunden: la política de protección decide qué puede hacer el usuario dentro de la app; el Acceso Condicional decide si llega a entrar, y eso depende del broker de identidad — lo tratamos en la pieza sobre SSO corporativo en una app móvil.
- No configura tu app. Los ajustes que IT quiera fijar sin publicar versión son managed configurations, otra pieza distinta: en Android se declaran en el manifiesto y se leen con
RestrictionsManager, como está detallado en la guía de app privada en managed Google Play.
Preguntas antes de firmar el alcance
- ¿Dispositivos corporativos inscritos, BYOD, o los dos?
- ¿Va a haber cuentas personales y corporativas en la misma app? Si sí, multi-identidad entra en el alcance.
- ¿Qué políticas concretas piensa aplicar IT? Pide la lista, no el titular.
- ¿Quién es el administrador de Intune y cuándo podemos probar contra su tenant?
- ¿La app necesita abrir contenido web propio? Confirma qué pasa con la política de forzar Edge.
Las cinco son del cliente. Las cinco se contestan en una llamada de media hora con su equipo de IT, y las cinco cambian la estimación si se contestan tarde.
Si estás preparando una app corporativa que tiene que pasar por el filtro de seguridad del cliente, esa llamada es parte de la primera fase en un proyecto de Flutter para empresas. Y si lo que tienes es un pliego escrito por otro, es justo lo que revisamos como CTO as a Service.
Fuente primaria, consultada el 14 de agosto de 2026: Intune App SDK en la documentación de Microsoft Intune.
