Explicación de NDES y SCEP: la columna vertebral de la inscripción automatizada de certificados

A medida que las organizaciones aceleran la adopción de Zero Trust, la autenticación de dispositivos y la infraestructura gestionada en la nube, el registro manual tradicional de certificados ya no es escalable. Ya sea para incorporar miles de portátiles mediante Intune, emitir certificados para el acceso VPN o habilitar la autenticación Wi-Fi en oficinas globales, el registro automatizado de certificados es esencial.

Aquí es donde SCEP (Simple Certificate Enrollment Protocol) y NDES (Network Device Enrollment Service) desempeñan un papel fundamental en los ecosistemas PKI de Microsoft. A pesar de su importancia, muchos administradores los implementan sin comprender completamente su funcionamiento, sus diferencias ni cómo protegerlos adecuadamente. Los servidores NDES mal configurados siguen siendo una de las vulnerabilidades PKI más comunes detectadas durante las auditorías de seguridad.

Respuesta rápida: ¿Qué son NDES y SCEP?

SCEP (Simple Certificate Enrollment Protocol) es el protocolo que permite a los dispositivos solicitar certificados mediante HTTP/HTTPS sin unirse a Active Directory. NDES (Network Device Enrollment Service) es la implementación de SCEP por parte de Microsoft, que actúa como puente entre los dispositivos compatibles con SCEP y ADCS. Sin NDES, las plataformas Intune y MDM no pueden emitir certificados desde una CA local.

Puntos Clave

• NDES es el puente necesario entre los dispositivos compatibles con SCEP (terminales administrados por Intune, dispositivos IoT, puertas de enlace VPN, dispositivos de red) y Microsoft ADCS. Sin NDES, estos dispositivos no pueden obtener certificados de una CA local.
• Los servidores NDES mal configurados son una de las vulnerabilidades más comunes en las infraestructuras de clave pública (PKI). Un punto final NDES expuesto a internet, una cuenta de servicio con privilegios excesivos o una plantilla de certificado débil pueden, de forma independiente, conducir a la emisión no autorizada de certificados.
• Según la encuesta Trust Pulse de DigiCert (2 de julio de 2025), casi la mitad de las empresas experimentaron interrupciones del servicio relacionadas con certificados durante el último año. Un servidor NDES mal configurado o no disponible interrumpe la autenticación de dispositivos en toda la organización simultáneamente.
• La propuesta SC-081v3 del Foro CA/Browser (abril de 2025) reduce la validez máxima de los certificados TLS públicos a 47 días para marzo de 2029. Esto hace que la inscripción automatizada en SCEP/NDES y las herramientas CLM sean esenciales; la renovación manual no puede soportar este ritmo a escala de flota de dispositivos.
• SCEP y NDES no serán reemplazados por ACME; cumplen funciones diferentes. SCEP/NDES gestiona los certificados de dispositivos para Intune, VPN y dispositivos de red. ACME gestiona los certificados de servidores y cargas de trabajo para canalizaciones de DevOps, Kubernetes y servicios nativos de la nube. La mayoría de las empresas necesitan ambos.

¿A quién debería importarle NDES y SCEP?

La implementación y la seguridad de NDES son responsabilidad de varios departamentos. Cada uno de los roles que se mencionan a continuación tiene un interés directo en que esto se haga correctamente.

Rol	POR QUÉ ES IMPORTANTE	Acción
Administradores de PKI	Implementación propia del servidor NDES, configuración de la plantilla de certificado para SCEP, configuración del agente de inscripción de CA y aplicación de la política de CA para los certificados emitidos por NDES.	Implemente NDES en un servidor dedicado (no en la CA); configure las plantillas con el uso de claves y EKU correctos, y sin claves privadas exportables; integre los registros de emisión de la CA con SIEM.
Arquitectos de seguridad	Es propietario del diseño de aislamiento de red, los estándares de endurecimiento de IIS y el modelo de privilegios de la cuenta de servicio NDES que determinan la superficie de ataque de la implementación de NDES.	Coloque NDES en una DMZ detrás de un proxy inverso o una puerta de enlace de aplicaciones; aplique el principio de mínimo privilegio para la cuenta de servicio de NDES; defina listas de control de acceso (ACL) de plantilla de certificado que restrinjan la inscripción de SCEP a dispositivos autorizados.
Equipos de plataforma/punto final	Gestiona la integración de Intune, MDM y administración de dispositivos que depende de NDES para la entrega de certificados a los dispositivos administrados.	Configure los perfiles SCEP de Intune que apunten al punto final HTTPS de NDES; pruebe la entrega de certificados a los tipos de dispositivos (Windows, iOS, Android, macOS); confirme que el almacén de confianza del dispositivo incluye la raíz de la CA emisora.
Equipos de cumplimiento	Debe demostrarse que la emisión de certificados a través de NDES se registra, se supervisa y se puede auditar; NDES es un punto de control crítico para la evidencia de autenticación basada en certificados.	Confirmar que los registros de emisión de CA capturen todos los certificados inscritos en SCEP; integrar los registros de NDES IIS con SIEM; incluir los certificados emitidos por NDES en el inventario trimestral de certificados y el alcance de la auditoría.
CISO	Considerar la entrada del registro de riesgos para NDES como una superficie de ataque de alto valor, ya que la vulneración de NDES permite la emisión no autorizada de certificados utilizables para la autenticación y el movimiento lateral.	Exigir que NDES se evalúe en cualquier auditoría de seguridad de PKI; financiar herramientas CLM para una visibilidad unificada de los certificados emitidos por NDES; incluir la disponibilidad de NDES en los informes de resiliencia de PKI.

¿Qué es SCEP?

SCEP, o Protocolo Simple de Inscripción de Certificados , es un protocolo desarrollado originalmente por Cisco para automatizar la inscripción de certificados en dispositivos de red que no pueden unirse fácilmente a Active Directory. A diferencia de los métodos de inscripción tradicionales basados ​​en AD, SCEP permite que los dispositivos soliciten certificados mediante HTTP/ HTTPS , se autentiquen con una clave secreta compartida o una contraseña de desafío y recuperen automáticamente los certificados firmados.

SCEP fue diseñado para dispositivos como enrutadores y conmutadores, puertas de enlace VPN, dispositivos de red, dispositivos IoT y dispositivos móviles. Con el tiempo, se ha convertido en el estándar de facto para la inscripción de certificados en plataformas de administración de dispositivos, incluyendo Microsoft Intune y muchas soluciones MDM.

¿Qué es NDES?

NDES (Servicio de inscripción de dispositivos de red) es la implementación de SCEP por parte de Microsoft. Actúa como puente entre los dispositivos y la Autoridad de certificación de Microsoft, lo que permite que los dispositivos que no pueden autenticarse a través de Active Directory obtengan certificados de forma segura. Sin NDES, SCEP no se puede utilizar con Microsoft ADCS.

En términos simples, así es como funciona:

1. Los dispositivos se comunican con NDES mediante SCEP
2. NDES valida la solicitud
3. NDES envía la solicitud a Microsoft CA
4. La CA emite el certificado.
5. NDES lo devuelve al dispositivo.

Requisitos previos antes de implementar NDES

Antes de implementar NDES, confirme que se cumplen todos los siguientes requisitos. La falta de un requisito previo es la causa más común de fallos en la instalación de NDES y errores de inscripción posteriores a la implementación.

Requisito previo	Requisito	Verificación de validación	Error común si falta	Propietario
Entorno ADCS	Al menos una CA emisora ​​que se ejecute en Windows Server 2012 R2 o posterior; la CA raíz debe ser accesible para la validación de la cadena.	Ejecutar certutil -ping contra la CA del servidor NDES para confirmar la conectividad RPC	La configuración de NDES falla con el error "No se puede contactar con la Autoridad de Certificación" durante la configuración.	Administrador de PKI
Servidor NDES dedicado	Windows Server 2016 o posterior; NDES NO debe estar instalado en el propio servidor CA; IIS debe estar instalado antes del rol NDES.	Confirme que el servidor esté unido al dominio y que el sitio web predeterminado de IIS esté en funcionamiento antes de instalar el rol NDES.	Si se instala en CA, NDES entrará en conflicto con los oyentes RPC de CA; la instalación puede tener éxito, pero la inscripción falla en tiempo de ejecución.	Administrador de PKI
Cuenta de servicio NDES	Cuenta de dominio dedicada (no administrador de dominio); debe pertenecer al grupo local IIS_IUSRS; debe tener permiso de inscripción en la plantilla de certificado SCEP; debe tener el derecho "Iniciar sesión como servicio".	Confirme que la cuenta NO es miembro de Administradores de dominio; confirme Inscribir ACE en la pestaña Seguridad de la plantilla.	Error HTTP 500 en la URL de NDES o fallo en la recuperación de la contraseña de desafío si la cuenta carece de derechos de inscripción en la CA.	Administrador de PKI / Arquitecto de seguridad
Plantilla de certificado	Plantilla configurada para SCEP: Uso de clave = Firma digital; EKU = Autenticación de cliente (y otros según sea necesario); clave privada no exportable; Proporcione en la solicitud el nombre del sujeto.	Abra la plantilla en certtmpl.msc; confirme el uso de claves, la EKU y la configuración de clave privada; confirme que la plantilla esté publicada en la CA emisora.	La CA rechaza la solicitud de certificado si la plantilla EKU no coincide con el uso previsto; NDES devuelve HTTP 400 al dispositivo solicitante.	Administrador de PKI
Certificado SSL para el punto final HTTPS de NDES	Certificado SSL/TLS válido vinculado al sitio NDES IIS; la CA emisora ​​debe ser de confianza para todos los dispositivos que usarán NDES; se exige TLS 1.2 o superior.	Acceda a la URL HTTPS de NDES desde un dispositivo de prueba y confirme que no haya ninguna advertencia de certificado; compruebe las configuraciones de IIS en inetmgr.	Los dispositivos rechazan la conexión NDES si el certificado SSL es autofirmado o emitido por una CA no confiable; Intune informa un error de inscripción.	Equipo de administración/plataforma de PKI
Acceso a la red	Los dispositivos deben alcanzar el punto final HTTPS de NDES en el puerto TCP 443; el servidor NDES debe alcanzar la CA en el puerto TCP 135 y puertos RPC dinámicos; se recomienda un proxy inverso o una puerta de enlace de aplicación para implementaciones con acceso a Internet.	Ejecutar Test-NetConnection -ComputerName ndes.contoso.com -Port 443 Desde un dispositivo de prueba; confirme que las reglas del firewall permiten CA RPC desde el servidor NDES.	Tiempos de espera de inscripción o errores de reinicio TCP en los dispositivos si el firewall bloquea NDES HTTPS; fallos silenciosos en el envío de CA si NDES no puede comunicarse con CA a través de RPC.	Arquitecto de seguridad / Equipo de redes

Por qué NDES sigue siendo importante en la infraestructura de clave pública moderna

Algunos administradores suponen que SCEP está obsoleto porque se creó hace décadas. Sin embargo, el uso de SCEP ha crecido considerablemente debido a las tendencias modernas en la gestión de dispositivos. Los siguientes tres casos prácticos ilustran por qué NDES sigue siendo esencial hoy en día.

1. Inscripción del certificado del dispositivo de Microsoft Intune

Las organizaciones que implementan Intune suelen depender de NDES para emitir certificados de autenticación de dispositivos, certificados Wi-Fi, certificados VPN y certificados de autenticación de correo electrónico. Sin NDES, Intune no puede emitir certificados desde ADCS local. Esto convierte a NDES en un requisito indispensable para cualquier implementación híbrida de Intune que utilice una CA interna en lugar de una CA en la nube.

2. Certificados de autenticación de cliente

NDES se utiliza habitualmente para emitir certificados de autenticación de cliente para la VPN Always-On de Windows, clientes VPN de terceros y arquitecturas de acceso remoto híbridas. Esto permite la autenticación VPN sin contraseña vinculada a la identidad del dispositivo , un control fundamental en los modelos de acceso a la red de confianza cero.

3. Inscripción de dispositivos de red e IoT

NDES permite emitir certificados a impresoras, cámaras, sistemas de fabricación y dispositivos de red. Estos dispositivos a menudo no pueden unirse a Active Directory, lo que convierte a SCEP en la única opción escalable. En entornos de tecnología operativa (OT) e industriales, donde el número de dispositivos asciende a miles, NDES, respaldado por PKIaaS (Infraestructura de Infraestructura como Servicio) , proporciona la infraestructura de emisión escalable que estos entornos requieren.

Cómo funciona NDES: descripción general de la arquitectura

Una implementación típica de NDES consta de cuatro componentes: el dispositivo solicitante (administrado por MDM o dispositivo de red), el servidor NDES, la Autoridad de Certificación (CA) de Microsoft y la plantilla de certificado configurada para SCEP.

Paso 1: El dispositivo solicita la inscripción.

El dispositivo se conecta al punto final HTTPS de NDES mediante SCEP. En el caso de los dispositivos administrados por Intune, esto se activa automáticamente mediante un perfil SCEP de Intune. El dispositivo genera un par de claves y crea una solicitud de firma de certificado (CSR) PKCS#10.

Paso 2: NDES emite una contraseña de desafío.

NDES genera una contraseña de un solo uso (OTP) que se utiliza para validar la solicitud. En las implementaciones integradas con Intune, Intune preautoriza la solicitud y proporciona la contraseña a través del conector NDES, por lo que no es necesario recuperar la OTP manualmente.

Paso 3: El dispositivo envía la solicitud de certificado.

El dispositivo envía su solicitud de firma de certificado junto con la contraseña de desafío a NDES mediante una solicitud HTTP POST al punto final SCEP. NDES valida el desafío antes de reenviar la solicitud a la CA.

Paso 4: NDES presenta la solicitud a la CA

NDES reenvía la solicitud a la CA de Microsoft utilizando las credenciales de la cuenta de servicio de NDES y la plantilla de certificado designada. La CA evalúa la solicitud en función de la política, el uso de claves, la EKU y la configuración del nombre del sujeto de la plantilla antes de emitir o rechazar el certificado.

Paso 5: Se emite el certificado

La CA firma el certificado y lo devuelve a NDES. El evento de emisión de la CA se registra en la base de datos y el registro de eventos de la CA. En este punto, la integración de SIEM debe capturar el evento de emisión para fines de auditoría.

Paso 6: El dispositivo recupera el certificado.

El dispositivo consulta el punto final NDES y recupera el certificado firmado. A continuación, lo instala en el almacén de certificados correspondiente (almacén de máquina para la autenticación del dispositivo, almacén de usuario para los certificados de usuario). En este punto, la plataforma CLM debe registrar este certificado en el inventario para su seguimiento y gestión de renovaciones.

Errores comunes de configuración de NDES detectados en evaluaciones de seguridad

En las evaluaciones de seguridad de PKI, aparecen de forma recurrente varias configuraciones erróneas de NDES. Cada una representa un vector de ataque real.

1. NDES expuesto directamente a Internet

Los puntos de conexión NDES suelen ejecutarse en IIS y pueden publicarse externamente sin protección. Esto permite a los atacantes intentar la inscripción de certificados, enumerar plantillas y explotar vulnerabilidades de IIS. NDES siempre debe protegerse mediante puertas de enlace de aplicaciones y reglas de acceso basadas en roles. Nunca publique la URL de NDES directamente en internet; siempre rediríjala a través de un proxy inverso o un proxy de aplicación de Azure que pueda aplicar la autenticación antes de que las solicitudes lleguen a NDES.

2. Cuentas de servicio con privilegios excesivos

NDES utiliza una cuenta de servicio para solicitar certificados a la CA. Si esta cuenta tiene permisos excesivos, los atacantes que la comprometan pueden emitir certificados de forma independiente. Este riesgo es especialmente grave, ya que los certificados pueden utilizarse para la autenticación y el movimiento lateral. La cuenta de servicio de NDES solo debe tener el permiso de inscripción en la plantilla SCEP designada, pertenencia a IIS_IUSRS local y derechos de inicio de sesión como servicio. Nunca debe ser miembro de Administradores de dominio ni de Administradores de CA.

3. Configuración de plantilla débil

En ocasiones, las plantillas utilizadas para SCEP se configuran para permitir la exportación de claves privadas, otorgar derechos de uso excesivamente amplios (por ejemplo, autenticación de cliente y servidor en la misma plantilla) y emitir certificados sin controles de aprobación del administrador. Estas configuraciones incorrectas pueden provocar el compromiso de la identidad y el uso indebido de certificados. Deshabilite siempre la exportación de claves privadas en las plantillas SCEP. Establezca el número mínimo de EKU requerido para el caso de uso. Considere habilitar la aprobación del administrador de la CA para plantillas con altos privilegios, incluso cuando se utilice SCEP.

4. Falta de monitoreo y registro

Muchas organizaciones implementan NDES pero nunca lo supervisan. Sin una supervisión y un registro adecuados, la emisión de certificados no autorizados pasa desapercibida, no se detecta el abuso de inscripciones y la respuesta a incidentes se dificulta. Integre los registros de eventos de la CA (ID de evento 4886 para solicitudes de certificados, ID de evento 4887 para emisión de certificados) con su SIEM. Configure alertas para picos anormales en el volumen de inscripciones desde una única IP o dispositivo. Utilice CBOM Secure para mantener un inventario criptográfico continuo de todos los certificados emitidos por NDES.

Mejores prácticas de seguridad para implementaciones de NDES

Para proteger NDES en entornos modernos, las organizaciones deben seguir estas mejores prácticas. Para obtener más información, consulte la guía complementaria: Mejores prácticas de seguridad de NDES.

1. Aislar servidores NDES

NDES nunca debe instalarse directamente en la CA. Implemente la solución en un segmento DMZ dedicado, detrás de un proxy inverso o una puerta de enlace de aplicación, con acceso de red limitado a la CA (solo puertos RPC de la CA, bloqueados desde todos los demás segmentos internos). Esto limita el alcance del ataque en caso de que el servidor NDES se vea comprometido.

2. Restringir los permisos de las plantillas

Las plantillas SCEP deben permitir solo los EKU necesarios, restringir los formatos de nombre de sujeto a "Suministrar" en la solicitud (validado mediante el desafío NDES), deshabilitar la exportación de clave privada y establecer permisos de inscripción solo para la cuenta de servicio NDES en lugar de para los equipos del dominio en general.

3. Supervisar la emisión de certificados

Registre todas las solicitudes SCEP mediante los registros de IIS y los registros de eventos de la CA. Supervise el uso de plantillas por nombre y cuenta solicitante. Genere alertas ante volúmenes de inscripción anormales (por ejemplo, más de 50 solicitudes de certificados por hora desde una sola fuente). Esto es especialmente importante para las plantillas que otorgan certificados de autenticación de cliente, ya que un atacante podría utilizarlos para el movimiento lateral.

4. Reforzar la configuración de IIS

Dado que NDES se ejecuta en IIS, desactive los módulos de IIS que no utilice, aplique TLS 1.2 o superior en el enlace HTTPS de NDES, aplique los encabezados de seguridad HTTPS (HSTS, X-Content-Type-Options, X-Frame-Options) y actualice el servidor periódicamente. El sitio de NDES en IIS debe ser el único sitio en el servidor; no aloje otras aplicaciones en él.

Dónde SCEP y NDES empiezan a mostrar limitaciones

A pesar de su amplia adopción, SCEP y NDES no fueron diseñados originalmente para los entornos nativos de la nube actuales. En las implementaciones modernas suelen surgir varios desafíos.

Contexto de seguridad limitado

SCEP se diseñó para ser sencillo, lo que significa que ofrece capacidades limitadas de validación de identidad. El mecanismo de contraseña de desafío es un secreto compartido, no una prueba de identidad criptográficamente protegida. A menudo es necesario añadir controles adicionales (como la preautorización de Intune mediante el conector NDES) para garantizar una autenticación sólida del dispositivo antes de la emisión del certificado.

Complejidad operativa

Las implementaciones de NDES requieren servidores dedicados, refuerzo de IIS, planificación de la exposición de la red, gestión de la configuración de plantillas y gestión del ciclo de vida de las cuentas de servicio. En entornos híbridos o multinube con múltiples instancias de NDES, esto genera una sobrecarga operativa significativa sin una herramienta CLM unificada que proporcione visibilidad en todas las instancias.

Desafíos de escala

Si bien SCEP funciona bien para dispositivos de punto final, es menos adecuado para cargas de trabajo dinámicas como contenedores, microservicios o instancias de nube efímeras. Estas cargas de trabajo modernas requieren ciclos de emisión de certificados más rápidos, mecanismos de verificación de identidad más robustos y certificados de corta duración. ACME gestiona estos escenarios de forma más eficaz.

El marco moderno de automatización de certificados: ACME

ACME (Automated Certificate Management Environment) se desarrolló para permitir una gestión totalmente automatizada del ciclo de vida de los certificados con una mínima intervención humana. A diferencia de SCEP, ACME se diseñó para entornos modernos y admite la emisión y renovación automatizadas de certificados, flujos de trabajo basados ​​en API, mecanismos de verificación de identidad y certificados de corta duración, en consonancia con los principios de confianza cero.

ACME resulta especialmente valioso para las canalizaciones de DevOps, los clústeres de Kubernetes, los servicios nativos de la nube y la autenticación entre servicios. Las empresas lo están adoptando cada vez más internamente para la gestión de identidades de cargas de trabajo, junto con SCEP/NDES para los certificados de dispositivos.

Comparación de SCEP, NDES y ACME en PKI empresarial

Cada tecnología cumple una función diferente. Las organizaciones suelen utilizarlas conjuntamente en lugar de elegir solo una.

Dimensión	SCEP / NDES	CUMBRE	Inscripción automática en AD
Caso de uso principal	Certificados de dispositivo para puntos finales administrados por Intune, clientes VPN, IoT y dispositivos de red.	Certificados de servidor y carga de trabajo para pipelines de DevOps, Kubernetes y servicios nativos de la nube.	Certificados de usuario y de equipo para sistemas Windows unidos a un dominio
Requisito del dispositivo	No requiere ser miembro de Active Directory; utiliza contraseña de desafío para la autenticación.	No requiere Active Directory; utiliza validación de dominio o autenticación mediante token de API.	Requiere ser miembro de Active Directory y tener una directiva de grupo.
Certificado de por vida	Admite certificados de dispositivos de mayor duración (normalmente: 1 año); renovación mediante una nueva solicitud SCEP.	Diseñado para certificados de corta duración (de días a 90 días); renovación automática integrada en el protocolo.	Admite cualquier período de validez configurado en la plantilla; renovación mediante GPO de inscripción automática.
Infraestructura requerida	Servidor NDES (servidor Windows dedicado + IIS), cuenta de servicio NDES, acceso RPC de CA	Punto final de CA compatible con ACME; no se requiere ningún servidor dedicado más allá de la propia CA.	Controlador de dominio, directiva de grupo, CA unida al dominio
Soporte en la nube/híbrido	Funciona con Intune a través del conector NDES; requiere un servidor NDES local para ADCS local.	Diseñado para CA en la nube; funciona sin infraestructura local.	Requiere Active Directory local; no es adecuado para dispositivos exclusivamente en la nube ni para dispositivos personales en el trabajo (BYOD).
Preparación para PQC	Limitado; depende de la configuración del algoritmo CA y de la plantilla; no hay negociación de algoritmos integrada.	Robusto; negociación de algoritmos integrada en el protocolo; listo para la migración a NIST FIPS 203/204/205.	Depende de la configuración de la plantilla CA; requiere una actualización de la plantilla para los algoritmos PQC.
Ideal para	Certificados de dispositivos Intune, certificados VPN, certificados Wi-Fi, identidad de dispositivos IoT	TLS del servidor web, identidad del contenedor, certificados de canalización CI/CD, certificados de servicio de corta duración	Certificados de usuario y de equipo Windows unidos a un dominio

Ejemplo real: Implementación de una empresa híbrida

Consideremos una empresa que adopta Zero Trust y migra a la nube simultáneamente. Podrían implementar NDES integrado con Intune para administrar certificados de dispositivos, la emisión basada en ACME para cargas de trabajo de contenedores y la inscripción automática de ADCS para servidores internos. Este modelo híbrido les permite mantener la compatibilidad con sistemas heredados al tiempo que modernizan la gestión del ciclo de vida de los certificados. Además, reduce la dependencia de contraseñas y refuerza los controles de acceso basados ​​en la identidad en todo el entorno.

Cómo elegir el método de inscripción adecuado

Si su enfoque se centra en dispositivos de usuario final o dispositivos de red que no pueden unirse a Active Directory, SCEP con NDES sigue siendo práctico y cuenta con amplio soporte. Si su enfoque se centra en cargas de trabajo modernas o entornos con alta automatización, ACME ofrece una mayor integración y escalabilidad. Si administra sistemas Windows unidos a un dominio mediante directivas de grupo, la inscripción automática en Active Directory es la opción más eficiente.

La mayoría de las empresas necesitarán las tres durante su transición hacia modelos de seguridad nativos de la nube. Una plataforma CLM unificada como CertSecure Manager proporciona una visión centralizada de las tres vías de emisión, lo que garantiza que ningún certificado escape al inventario, independientemente de cómo se haya emitido.

El futuro de la inscripción en certificados empresariales

La autenticación basada en certificados se está convirtiendo rápidamente en el mecanismo predeterminado para proteger los entornos empresariales. A medida que las organizaciones avanzan hacia la autenticación sin contraseña, la verificación de la identidad de los dispositivos, los modelos de acceso de confianza cero y la arquitectura nativa de la nube, la automatización de certificados se convierte en una capacidad de seguridad fundamental en lugar de una función específica de la infraestructura de clave pública (PKI).

Es probable que SCEP y NDES sigan utilizándose para el registro de dispositivos, mientras que la adopción de ACME continúa creciendo para la gestión de identidades de carga de trabajo y la automatización de la infraestructura. El NIST finalizó las normas FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA) en agosto de 2024. Las organizaciones que no hayan comenzado a planificar la preparación para PQC deberán actualizar los perfiles de algoritmos de CA y las plantillas de certificados para admitir algoritmos post-cuánticos. Comience con la evaluación de preparación para PQC y el Centro de Excelencia de PQC para la planificación de la migración alineada con el NIST.

Cómo puede ayudar la consultoría de cifrado

Encryption Consulting cuenta con una amplia experiencia en la implementación de soluciones PKI integrales para empresas y gobiernos. Ofrecemos servicios profesionales y nuestra plataforma de automatización ( CertSecure Manager ) para garantizar que su PKI sea segura, resiliente y esté preparada para el futuro.

Servicios de PKI

Servicios de asesoramiento, diseño e implementación de extremo a extremo para ayudar a las organizaciones a construir, modernizar y gobernar entornos seguros de infraestructura de clave pública.

Planificación de proyectos

Evaluamos su entorno criptográfico, revisamos las configuraciones, dependencias y requisitos de PKI y consolidamos los hallazgos en un plan de proyecto estructurado y aprobado por el cliente.

Desarrollo de CP/CPS

Desarrollamos políticas de certificación (CP) y declaraciones de prácticas de certificación (CPS) alineadas con la RFC 3647. Estos documentos se personalizan según los requisitos normativos, de seguridad y operativos de su organización.

Diseño e implementación de PKI

Diseñamos e implementamos infraestructuras PKI resilientes, incluyendo CA raíz sin conexión, CA emisoras, servidores NDES e integración de HSM, según las necesidades del cliente. Los entregables incluyen el documento de diseño de PKI, guías de compilación, scripts de ceremonias y configuraciones del sistema. Una vez implementada, realizamos pruebas exhaustivas, validación, optimización y sesiones de transferencia de conocimientos para capacitar a su equipo.

Continuidad del negocio y recuperación ante desastres

Luego de la implementación, desarrollamos e implementamos estrategias de continuidad comercial y recuperación ante desastres, realizamos pruebas de conmutación por error y documentamos flujos de trabajo operativos para toda la infraestructura de PKI y HSM, respaldados por una guía integral de operaciones de PKI.

Soporte y mantenimiento continuos (opcional)

Tras la implementación, ofrecemos un paquete de soporte anual por suscripción que proporciona una cobertura integral para los componentes PKI, CLM y HSM. Esto incluye respuesta a incidentes, resolución de problemas, optimización del sistema, gestión del ciclo de vida de los certificados, actualizaciones de CP/CPS, archivo de claves, actualizaciones de firmware de HSM, registro de auditoría y gestión de parches.

Este enfoque garantiza que su infraestructura PKI no solo sea segura y compatible, sino también escalable, resiliente y totalmente alineada con sus objetivos operativos y regulatorios a largo plazo.

Administrador de CertSecure

CertSecure Manager de Encryption Consulting es una solución de gestión del ciclo de vida de los certificados que simplifica y automatiza todo el proceso, lo que le permite centrarse en la seguridad en lugar de en las renovaciones.

• Automatización para certificados de corta duración: Con la adopción generalizada de ACME y los certificados TLS de 90/47 días, la renovación manual ya no es una opción práctica. CertSecure Manager automatiza la inscripción, la renovación y la implementación para garantizar que los certificados nunca caduquen sin previo aviso.
• Integración perfecta de DevOps y la nube: Los certificados se pueden aprovisionar directamente en servidores web e instancias en la nube, y se integran con herramientas de registro modernas como Datadog y Splunk, herramientas ITSM como ServiceNow y herramientas DevOps como Terraform y Ansible.
• Compatibilidad con múltiples CA: Muchas organizaciones utilizan varias autoridades de certificación (CA interna de Microsoft, CA públicas como DigiCert y GlobalSign, etc.). CertSecure Manager se integra con estas fuentes, proporcionando una plataforma unificada para la emisión y la gestión del ciclo de vida de las certificaciones en los procesos de inscripción SCEP/NDES y ACME.
• Políticas unificadas de emisión y renovación: CertSecure Manager aplica de forma coherente los tamaños de clave, los algoritmos y las reglas de renovación de su organización en todos los certificados, garantizando que cada certificado cumpla siempre con sus estándares de seguridad.
• Monitoreo proactivo y pruebas de renovación: La monitorización continua, combinada con pruebas simuladas de renovación y caducidad, garantiza la identificación de riesgos antes de que los certificados afecten a los sistemas de producción.
• Visibilidad y cumplimiento centralizados: Un panel consolidado muestra todos los certificados, longitudes de clave, algoritmos fuertes y débiles, y sus fechas de vencimiento. Los registros de auditoría y la aplicación de políticas simplifican el cumplimiento con PCI DSS, HIPAAy otros marcos.

Si te preguntas por dónde empezar a proteger tu infraestructura de clave pública (PKI), Encryption Consulting te ofrece sus servicios de soporte . Puedes contar con nosotros como tu socio de confianza; te guiaremos en cada paso con claridad, seguridad y experiencia práctica.

Conclusión

La infraestructura de clave pública (PKI) empresarial está evolucionando de una herramienta de seguridad de backend a una infraestructura de identidad centralizada. Comprender cómo interactúan SCEP, NDES y ACME permite a las organizaciones crear flujos de gestión de certificados escalables que admiten tanto entornos heredados como cargas de trabajo modernas en la nube. Al combinar los fundamentos tradicionales de la PKI con marcos de automatización modernos, las empresas pueden avanzar hacia una seguridad más sólida basada en la identidad sin sacrificar la eficiencia operativa.

NDES sigue siendo esencial para las implementaciones híbridas de Intune y la inscripción de certificados en dispositivos que no pertenecen a un dominio, pero debe implementarse y protegerse con el mismo rigor que la propia CA. Considere cada servidor NDES mal configurado como una posible puerta trasera para la emisión de certificados. Invierta en herramientas CLM para mantener una visibilidad completa de los certificados emitidos por NDES y comience a planificar la preparación para PQC ahora, de modo que las transiciones de algoritmos no requieran reconstrucciones de CA de emergencia cuando lleguen los plazos reglamentarios.

Preguntas frecuentes

¿Cuál es la principal conclusión de NDES y SCEP explicados: La columna vertebral de la inscripción automatizada de certificados?

SCEP sigue siendo el protocolo de facto para la inscripción automatizada de certificados de dispositivos en entornos PKI de Microsoft, y NDES es el puente necesario entre los dispositivos compatibles con SCEP y ADCS. Sin NDES, Intune, las plataformas MDM y los dispositivos que no pertenecen a un dominio no pueden obtener certificados de una CA local. Los servidores NDES mal configurados son una de las vulnerabilidades de PKI más explotadas y deben tratarse con el mismo rigor de seguridad que la propia CA.

¿Por qué son importantes NDES y SCEP para los equipos de PKI empresariales?

Los equipos de PKI empresarial son responsables de la infraestructura de certificados de la que dependen los sistemas de acceso Intune, MDM, VPN, Wi-Fi y Zero Trust. NDES es el mecanismo mediante el cual estos sistemas obtienen certificados de ADCS para dispositivos que no pertenecen a un dominio. Según la encuesta Trust Pulse de DigiCert (2 de julio de 2025), casi la mitad de las empresas experimentaron interrupciones del servicio relacionadas con certificados durante el último año. Un servidor NDES mal configurado o no disponible puede interrumpir la autenticación de dispositivos en toda la organización simultáneamente.

¿Qué riesgos aumentan si NDES y SCEP no están debidamente protegidos?

Entre los riesgos se incluyen: un punto final NDES expuesto a Internet permite a los atacantes enumerar las plantillas de certificados e intentar la inscripción no autorizada; una cuenta de servicio con privilegios excesivos permite a los atacantes suplantar su identidad y emitir certificados de forma independiente; una configuración débil de la plantilla con claves privadas exportables crea vectores de compromiso de identidad; y la falta de monitorización implica que la emisión de certificados fraudulentos pasa desapercibida hasta que se produce un incidente.

¿Qué equipos deberían ser responsables del despliegue y la seguridad de NDES y SCEP?

Los administradores de PKI son responsables del despliegue del servidor NDES, la configuración de la plantilla de certificados y la política de CA. Los arquitectos de seguridad son responsables del diseño del aislamiento de la red y los estándares de endurecimiento de IIS. Los equipos de plataforma y endpoints son responsables de la integración de MDM/Intune y los perfiles de inscripción de dispositivos. Los equipos de cumplimiento son responsables de los requisitos del registro de auditoría y la evidencia de monitoreo. Los CISO son responsables de la entrada en el registro de riesgos para NDES como una superficie de ataque de alto valor debido a su función en la emisión de certificados para la autenticación.

¿Cómo se relacionan NDES y SCEP con la gestión del ciclo de vida de los certificados?

NDES y SCEP gestionan la inscripción inicial de certificados y las solicitudes de renovación de los dispositivos. La gestión del ciclo de vida de los certificados (CLM) proporciona la capa operativa más amplia que rastrea, supervisa y administra todos los certificados en el entorno. CertSecure Manager se integra con los flujos de inscripción de SCEP/NDES y ofrece visibilidad unificada de los certificados emitidos por ADCS, los certificados de CA públicos y los certificados emitidos en la nube en un único panel de control con alertas de caducidad automatizadas y flujos de trabajo de renovación.

¿Cómo deberían las organizaciones medir el éxito tras la implementación de NDES?

Las métricas clave incluyen: porcentaje de dispositivos objetivo inscritos correctamente a través de SCEP/NDES (objetivo: 100 % de los dispositivos administrados por MDM); número de intentos fallidos de inscripción de SCEP por semana (objetivo: tendencia a cero después de la estabilización inicial); fallos de autenticación relacionados con la caducidad de certificados causados ​​por certificados emitidos por NDES por trimestre (objetivo: cero); tiempo para detectar un certificado no autorizado o fraudulento emitido a través de NDES (objetivo: el mismo día a través de alertas SIEM); y disponibilidad del servidor NDES (objetivo: mínimo del 99.9 %).

¿Qué aspectos deben auditarse o supervisarse periódicamente en una implementación de NDES?

Supervise continuamente: el volumen de solicitudes de inscripción de SCEP y las tasas de fallos; los certificados emitidos a través de NDES en la base de datos de la CA; el estado del grupo de aplicaciones IIS de NDES; y el acceso a la red del punto final de NDES desde direcciones IP de origen inesperadas. Realice auditorías trimestrales: los permisos de la cuenta de servicio de NDES conforme a los requisitos de privilegios mínimos; la configuración de la plantilla de certificado para SCEP; la configuración de IIS para la aplicación de la versión TLS; y el nivel de parches del sistema operativo del servidor NDES.

¿Cómo afecta NDES a los entornos de nube, híbridos o con múltiples autoridades de certificación?

En entornos híbridos donde Intune administra dispositivos tanto nativos de la nube como locales, NDES es el puente necesario para emitir certificados desde ADCS local a dispositivos administrados en la nube. En entornos con múltiples CA, las organizaciones pueden ejecutar varias instancias de NDES. Sin herramientas de CLM que proporcionen visibilidad unificada, los certificados emitidos por diferentes instancias de NDES en distintas CA crean puntos ciegos en el inventario. CBOM Secure automatiza el descubrimiento criptográfico en estos entornos híbridos para mantener un inventario de certificados completo y auditable.

¿Qué requisitos previos se necesitan antes de implementar NDES?

Los requisitos previos incluyen: un entorno ADCS en funcionamiento con al menos una CA emisora; Windows Server 2016 o posterior para la función NDES; una cuenta de servicio dedicada con derechos de inscripción de CA y acceso a IIS (no un administrador de dominio); una plantilla de certificado configurada para la inscripción SCEP con el uso de clave correcto (firma digital), EKU y sin claves privadas exportables; IIS instalado en el servidor NDES; y un certificado SSL válido para el punto final HTTPS de NDES. NDES no debe estar instalado en el propio servidor de CA.

¿Qué errores comunes deben tener en cuenta los administradores al implementar NDES?

Los errores comunes incluyen: error HTTP 403 en la URL de NDES causado por problemas de permisos de IIS o de identidad del grupo de aplicaciones; fallos en la recuperación de la contraseña de desafío causados ​​por la falta de permisos de inscripción de CA en la cuenta de servicio de NDES; rechazos de solicitudes de certificado causados ​​por una configuración incorrecta de la plantilla o la falta de EKU; bloqueo del grupo de aplicaciones de NDES causado por problemas de memoria o del módulo de IIS; y dispositivos que no pueden confiar en el certificado SSL de NDES porque la CA emisora ​​no está en el almacén de confianza del dispositivo.