Por qué aparece «Windows protegió su PC» en Windows

Un repaso práctico de SmartScreen, la firma de código, los certificados EV/OV y la distribución vía MSIX/Store

Al crear y distribuir una aplicación de Windows, el primer obstáculo con el que suele toparse el desarrollador es esta advertencia.

Windows protegió su PC
Microsoft Defender SmartScreen impidió el inicio de una aplicación no reconocida.

Cuando aparece esta advertencia, el usuario se inquieta. Y el desarrollador también se pregunta: «no es un virus, ¿por qué se bloquea?» o «firmé el código, ¿por qué sigue apareciendo la advertencia?».

Este artículo repasa la advertencia de SmartScreen al distribuir aplicaciones de Windows desde la perspectiva de la firma de código, los certificados EV/OV, MSIX, Microsoft Store, ClickOnce y la distribución interna.

1. En una frase

En la distribución de aplicaciones de Windows, la firma de código es necesaria.
Pero la firma de código no es una fórmula mágica que elimine siempre la advertencia de SmartScreen.

Lo importante es separar el análisis en tres aspectos.

A grandes rasgos, esta es una guía de decisión.

2. SmartScreen no es solo un «veredicto de virus»

Cuando aparece la advertencia de SmartScreen, el usuario piensa: «¿esta aplicación es peligrosa?».

Pero SmartScreen no se limita a evaluar simplemente si algo «es un virus o no». Según la explicación de Microsoft, para los archivos descargados observa principalmente esta información de reputación.

Lo importante aquí es que un archivo recién creado todavía no tiene reputación.

Aunque para el propio equipo sea una aplicación legítima, desde el punto de vista de Windows es «un archivo que se ve por primera vez». Incluso estando firmado, puede aparecer la advertencia de SmartScreen mientras la reputación del hash del archivo o del editor no sea suficiente.

En otras palabras, es más fácil de entender la advertencia de SmartScreen así:

No significa que se haya determinado que es malware.
Pero sí significa que Windows todavía no lo considera suficientemente confiable.

Si no se entiende esta diferencia, se producen malentendidos del tipo «firmé el archivo y no se soluciona» o «compré un certificado EV y no cambió nada».

3. Qué garantiza la firma de código

Lo que garantiza la firma de código son, principalmente, dos cosas.

1. Que el archivo fue firmado por el editor que se muestra
2. Que el archivo no fue alterado después de la firma

Dicho de otro modo, no garantiza directamente lo siguiente.

• Que la aplicación sea absolutamente segura
• Que la aplicación no tenga errores
• Que la advertencia de SmartScreen no vaya a aparecer nunca
• Que la política corporativa la permita siempre

Aun así, la firma de código es casi indispensable.

Sin firma, el usuario no puede saber quién es el editor. En entornos corporativos, un archivo sin firmar puede ser bloqueado por App Control, EDR, Defender, un proxy o una puerta de enlace de correo. Al crear actualizaciones automáticas, la firma también es importante para verificar que el archivo de actualización es auténtico.

En resumen, la firma de código no sirve solo para «eliminar la advertencia»: es la base de la distribución, las actualizaciones, las auditorías y la adopción en empresas.

4. «Con un certificado EV desaparece la advertencia desde el principio» es una idea desactualizada

Antes existía la idea generalizada de que usar un certificado de firma de código EV recibía un trato favorable en SmartScreen.

Pero actualmente, comprar un certificado EV con el único objetivo de evitar SmartScreen es, cuando menos, una decisión arriesgada. La documentación para desarrolladores de Microsoft, SmartScreen reputation for Windows app developers, indica explícitamente que «los certificados EV ya no evitan SmartScreen» y que «pagar el sobreprecio de un EV con el único fin de evitar la advertencia de SmartScreen ya no está justificado». En la misma página, la tabla por tipo de certificado agrupa OV y EV en la misma fila de «certificado válido (OV/EV)», y describe el comportamiento en la primera descarga como «advertencia hasta que se acumula reputación». Un archivo firmado con EV debe considerarse, igual que uno firmado con OV, sujeto a este mismo proceso de acumulación de reputación.

Esto no significa que el certificado EV carezca por completo de sentido.

• Se valora la verificación de identidad más estricta en procesos de adquisición corporativa
• La revisión de seguridad de un socio comercial exige EV
• Ya se dispone de un certificado EV y se continúa usándolo

Si existen estos motivos, es razonable usarlo.

Sin embargo, no se recomienda comprar un certificado EV únicamente con este objetivo.

Comprar un certificado EV para eliminar la advertencia de SmartScreen desde el principio

Si ese es el objetivo, conviene reconsiderar primero el canal de distribución, el método de firma, la explicación a los primeros usuarios, la frecuencia de actualización y si es posible distribuir a través de la Store.

5. Opciones de firma

A continuación se organizan las opciones de firma y distribución más habituales para aplicaciones de Windows.

Microsoft Store / MSIX

Para distribuir al público general, lo primero que conviene evaluar es Microsoft Store.

En particular, la combinación de MSIX con la distribución a través de la Store es ventajosa tanto para la gestión de certificados como para la advertencia de SmartScreen. Como los paquetes MSIX enviados a la Store son refirmados por Microsoft, también se reduce la carga de comprar y renovar certificados de forma individual.

Sin embargo, no todas las aplicaciones de Windows son adecuadas para MSIX.

• Depende profundamente de servicios de Windows
• Requiere un controlador (driver)
• Incluye una extensión de shell
• Tiene registros COM antiguos o recursos de ActiveX
• Necesita cambios complejos del sistema operativo durante la instalación

En estos casos, a veces resulta más natural usar MSI o un instalador tradicional en lugar de MSIX.

Azure Artifact Signing

Azure Artifact Signing es un servicio de firma de código en la nube ofrecido por Microsoft. Antes se llamaba Trusted Signing, y el nombre oficial actual es Azure Artifact Signing (Artifact Signing). La propia página de producto de Microsoft lo describe como «Artifact Signing (formerly Trusted Signing)». Todavía existen muchos artículos y documentos internos que usan el nombre anterior, así que al buscar conviene probar con ambos nombres. La documentación oficial está en Microsoft Learn: What is Artifact Signing? y en Azure: Artifact Signing (formerly Trusted Signing).

Su atractivo es que no requiere un token USB físico y es fácil de integrar en CI/CD. Es una opción sólida para firmar distribuciones fuera de la Store, pero tiene condiciones de región y de cuenta que deben cumplirse.

Según la documentación de Microsoft vigente en 2026, para organizaciones el servicio cubre Estados Unidos, Canadá, la UE y el Reino Unido, y para desarrolladores individuales, Estados Unidos y Canadá. Si se va a usar desde una empresa o como particular en Japón, es imprescindible verificar las condiciones de uso. Si no se puede utilizar, el certificado de firma de código OV tradicional es una alternativa realista.

Además, firmar con Azure Artifact Signing tampoco otorga confianza inmediata en SmartScreen. Al igual que con un certificado OV, la reputación se acumula en función del historial de distribución.

Certificado de firma de código OV

Cuando desarrolladores o empresas de Japón distribuyen aplicaciones de Windows fuera de la Store, el certificado de firma de código OV sigue siendo una opción realista.

Al usar un certificado OV, se muestra al usuario el nombre del editor, lo cual es claramente mejor que no tener firma. Sin embargo, en aplicaciones o archivos nuevos puede seguir apareciendo la advertencia de SmartScreen.

Al usar un certificado OV conviene tener en cuenta estos puntos.

• Usar el mismo nombre de editor de forma continua
• Firmar siempre como el mismo editor
• No modificar el archivo después de firmarlo
• Añadir marca de tiempo (timestamp)
• Revisar no solo el EXE, sino también los DLL, el MSI y el actualizador
• Preparar un plan de transición para la renovación del certificado

Certificado autofirmado

El certificado autofirmado es práctico para desarrollo y verificación.

Pero, en principio, no sirve para distribución pública, porque desde el Windows del usuario ese certificado no es de confianza.

El certificado autofirmado puede usarse en entornos como estos.

• El PC local del desarrollador
• El entorno de verificación de los evaluadores (testers)
• Equipos internos donde se puede distribuir el certificado de confianza mediante Intune o GPO
• Entornos cerrados donde la configuración de los equipos se controla por completo

Incluso al usar un certificado autofirmado, hay que gestionar cuándo se eliminará, quién lo agregó como confiable y si existe el riesgo de que se mezcle con el entorno de producción.

6. Qué se debe firmar en la práctica

No basta con decir «ya firmé el EXE y con eso termina».

En la distribución de aplicaciones de Windows conviene revisar de forma sistemática qué elementos deben firmarse.

Al usar SignTool, en el Windows SDK actual es importante especificar /fd y /td. Lo habitual es indicar SHA256.

signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 /a .\MyApp.exe
signtool verify /pa /v .\MyApp.exe

El significado de cada opción es el siguiente.

La URL del servidor de marca de tiempo debe ser la que indica el emisor del certificado. En el ejemplo de la documentación de SignTool de Microsoft se usa http://timestamp.digicert.com, y en el procedimiento de firma de Artifact Signing se usa https://timestamp.acs.microsoft.com. Al añadir la marca de tiempo se registra que el certificado era válido en el momento de la firma, de modo que la firma sigue siendo utilizable incluso después de que el certificado caduque.

La forma de indicar el certificado varía según el entorno.

Un detalle fácil de pasar por alto es que, a menos que se indique /sm, SignTool solo consulta el almacén personal del usuario que ejecuta el comando. Es habitual que aparezca el error «no se encontró el certificado» porque el certificado se instaló en el almacén de «Equipo local» pero no se escribió /sm, o porque la compilación se ejecuta con una cuenta de servicio mientras el certificado está en el almacén personal de otro usuario. Al firmar desde CI, conviene determinar primero en qué cuenta y en qué almacén se encuentra el certificado.

Para confirmar si la firma se realizó correctamente, se verifican estos tres puntos.

• Que signtool verify /pa /v .\MyApp.exe se ejecute correctamente
• Que el código de salida de ese comando sea 0 (en PowerShell, revisar $LASTEXITCODE justo después)
• Que, al abrir las propiedades del archivo en el Explorador, la pestaña «Firmas digitales» muestre el editor y la marca de tiempo

El punto clave es firmar el artefacto final.

Si se reescribe el EXE después de firmarlo, se sustituyen archivos dentro del ZIP o se modifican archivos incrustados después de crear el instalador, la firma puede romperse o el resultado de la verificación puede no ser el esperado.

En el pipeline de compilación conviene fijar este orden.

Compilación (build)
  ↓
Recolección de archivos dependientes
  ↓
Creación del instalador / paquete
  ↓
Firma
  ↓
Verificación de la firma
  ↓
Registro del hash
  ↓
Distribución

7. Consideraciones según el método de distribución

Instalador MSI / EXE

Al distribuir mediante un instalador MSI o EXE, hay que firmar siempre el archivo que el usuario ejecuta primero.

Además, hay que revisar como objetos de firma los EXE y DLL que se colocan después de la instalación. Aunque solo el instalador esté firmado, si el actualizador o los helper que se instalan después no lo están, en entornos corporativos pueden bloquearse.

Los puntos a considerar son, en general, los siguientes.

• Firmar el propio instalador
• Firmar también los EXE/DLL que contiene
• Separar los procesos que requieren elevación de UAC
• Auditar por separado el actualizador y los helper de servicio
• Mantener estable la URL de la página de descarga
• Indicar el nombre del editor a los primeros usuarios

MSIX

MSIX es un formato con una fuerte coherencia como paquete.

Si se puede distribuir por la Store, resulta bastante más manejable tanto en cuanto a la advertencia de SmartScreen como a la gestión de certificados. En cambio, en la instalación lateral (sideload) interna o en la distribución fuera de la Store, hay que diseñar cuidadosamente la firma del paquete MSIX y la confianza del certificado.

A continuación, algunos puntos a tener en cuenta.

• En desarrollo y verificación, un certificado autofirmado es aceptable
• En la distribución de producción, usar un método de firma con confianza pública
• Hacer coincidir el Publisher del appxmanifest con el Subject del certificado
• En la distribución fuera de la Store, asumir que puede aparecer la advertencia de SmartScreen
• Verificar de antemano si existe alguna integración con el sistema operativo poco adecuada para MSIX

ClickOnce

ClickOnce es útil para distribuir a usuarios estándar aplicaciones de negocio en .NET, como las de WinForms o WPF.

Sin embargo, usar ClickOnce no hace que el problema de SmartScreen desaparezca por sí solo. Intervienen el canal por el que el usuario descarga y ejecuta la aplicación, la firma del manifiesto, el origen de distribución y los cambios de archivo en cada actualización.

Con ClickOnce conviene revisar estos puntos.

• La firma del manifiesto de aplicación y del manifiesto de implementación
• La gestión de la URL de origen o de la carpeta compartida de distribución
• El tratamiento de un cambio de certificado en una actualización
• Si el proxy interno o Defender bloquean el proceso
• La información que se da al usuario en la primera instalación

La fortaleza de ClickOnce es que «se distribuye con facilidad», pero si no se diseña también la confianza del editor y el canal de distribución, en la práctica el proceso se detiene.

Distribución xcopy / ZIP

Distribuir simplemente colocando una carpeta o descomprimiendo un ZIP es un método sencillo.

Puede ser válido en redes cerradas o para herramientas internas. Pero, en la distribución web dirigida al público general, es también el método más expuesto a SmartScreen, Defender y Mark of the Web.

El término Mark of the Web (MOTW) que acaba de aparecer es una secuencia de datos alternativa llamada Zone.Identifier que el navegador o el cliente de correo añade a los archivos descargados. Es una marca que indica «este archivo proviene de internet», y se usa en la verificación de SmartScreen, en el bloqueo de macros de Office y en la determinación de la política de ejecución de PowerShell (RemoteSigned), entre otros casos. La marca se puede quitar abriendo las propiedades del archivo en el Explorador y marcando «Desbloquear» en la sección «Seguridad», o con el cmdlet Unblock-File de PowerShell. Que la marca se transmita o no a los archivos internos al descomprimir un ZIP depende de la herramienta usada para la extracción. El tema se trata en detalle en el capítulo «Zone.Identifier (Mark of the Web) y Unblock-File» de La directiva de ejecución de PowerShell y la firma de scripts.

Si se usa la distribución tipo xcopy, conviene respetar estos puntos.

• Firmar los EXE/DLL
• No confiar solo en el ZIP: verificar también los archivos que contiene
• Fijar el origen de distribución
• Indicar de forma explícita la versión, el hash y el historial de cambios
• Si se añade actualización automática más adelante, incluir verificación de firma

No se trata de «es fácil porque no se crea un instalador», sino de «asumir uno mismo la responsabilidad que normalmente tiene el instalador».

Actualizador propio

Un actualizador propio es práctico, pero constituye en sí mismo un límite de seguridad.

El actualizador obtiene archivos nuevos y reemplaza los existentes. En algunos casos se ejecuta con privilegios de administrador. Si algo falla aquí, es más peligroso que un fallo en la propia aplicación.

Como mínimo, hay que verificar lo siguiente.

• Firmar los metadatos de actualización
• Incluir en los metadatos la versión, el hash, el tamaño, el canal (channel) y la fecha de expiración
• Verificar el hash y la firma después de la descarga
• Detenerse en modo fail-closed si falla la verificación
• Preparar un procedimiento de rollback
• Definir cómo se actualiza el propio actualizador
• Separar la clave de firma de producción del entorno de desarrollo

Este tema se entiende mejor si se considera junto con el artículo «Diseño de seguridad de las actualizaciones automáticas».

8. En la distribución interna, no basta con mirar solo SmartScreen

En el caso de las aplicaciones internas, existe un malentendido frecuente.

Como solo se usa internamente, no hace falta firmar

Esto es peligroso.

En un entorno interno intervienen, además de SmartScreen, varios mecanismos más.

En particular, en los entornos que usan App Control for Business, el problema no es solo «si está firmado», sino también «si ese editor está permitido», «si pasa por un managed installer» y «si el hash o la ruta están permitidos».

La propia guía de implementación de Microsoft plantea el criterio de aplicar primero un cambio de política de App Control en modo de auditoría, comprobar que los eventos de bloqueo son los esperados y solo después extenderlo al modo forzado (enforced).

En la distribución interna, resulta realista diseñar el proceso en este orden.

1. Separar los equipos de destino
   - Desarrolladores
   - Evaluadores (testers)
   - Algunos departamentos
   - Toda la empresa

2. Decidir el canal de distribución
   - Intune
   - GPO + recurso compartido de archivos
   - Portal interno
   - VDI / RemoteApp
   - Distribución manual en red cerrada

3. Definir las reglas de confianza
   - Reglas de editor
   - Distribución de certificados
   - Managed installer
   - Permisos por hash
   - Permisos por ruta

4. Verificar en modo de auditoría
   - Qué se bloquea
   - Qué DLL o helper quedan sin cubrir
   - Si en una actualización se trata como un archivo distinto

5. Implementar por etapas
   - Distribuir a un grupo pequeño
   - Revisar los registros (logs)
   - Ajustar las reglas de permiso
   - Ampliar el alcance

El punto clave de la distribución interna no es evitar SmartScreen, sino construir un canal de distribución que resulte explicable para Windows.

9. Errores comunes y la forma correcta de pensarlos

10. Cómo explicar la situación a los usuarios en el lanzamiento inicial

En una aplicación nueva, durante las primeras semanas o con los primeros usuarios puede aparecer la advertencia de SmartScreen.

En ese momento, no conviene limitarse a decirle al usuario «ejecútelo aunque aparezca la advertencia». Una explicación segura debe incluir la información que se debe verificar.

Estos son los elementos que debe incluir la comunicación.

• La URL de descarga oficial
• El nombre del editor que se muestra
• El nombre del archivo
• El número de versión
• La fecha de publicación
• El hash SHA-256, si es necesario
• La forma de comprobar que está firmado
• No ejecutar archivos obtenidos por canales desconocidos

Por ejemplo, para uso interno, una comunicación segura sería así.

Esta aplicación se distribuye únicamente desde la siguiente página del portal interno.
Verifique que el nombre de editor mostrado sea «○○ Corporation».
No ejecute archivos EXE recibidos por adjunto de correo o reenviados por chat.
Si aparece la advertencia de SmartScreen, comparta la pantalla con el Departamento de Sistemas.

Para el público general, conviene priorizar la distribución por Microsoft Store o incluir en la página de descarga una explicación sobre cómo verificar el editor.

Qué hace el usuario en la pantalla de advertencia

En el material informativo conviene detallar incluso dónde debe hacer clic el usuario. En el cuadro de diálogo de advertencia de SmartScreen, el único botón disponible en el estado inicial es «No ejecutar». Para ejecutar el archivo, hay que seguir este orden.

Cuadro de diálogo «Windows protegió su PC»
  → Seleccionar «Más información»
  → Se muestra el nombre de la aplicación (nombre del archivo) y el editor
  → Pulsar el botón «Ejecutar de todos modos»

La documentación para desarrolladores de Microsoft también explica que, para un archivo sin firmar, «para ejecutar la aplicación es necesario seleccionar Ejecutar de todos modos». En el texto de la comunicación, además de estos dos pasos, el punto clave es pedir al usuario que confirme que el nombre de editor mostrado en medio del proceso corresponde al de la propia empresa. Si el nombre de editor aparece como «Editor desconocido», significa que el archivo no está firmado o que la firma está dañada.

Además, según la configuración de política de la empresa, este botón «Ejecutar de todos modos» puede estar deshabilitado y no dejar avanzar. En la comunicación interna conviene incluir también un contacto para ese caso.

Tiempo estimado hasta que desaparece la advertencia

Es habitual preguntarse «¿cuánto hay que distribuir para que desaparezca la advertencia?», pero Microsoft no publica un umbral concreto. La explicación de la documentación para desarrolladores es que «no existe un umbral exacto, pero puede requerirse varias semanas y cientos de instalaciones limpias de un conjunto amplio de usuarios». Además, se indica explícitamente lo siguiente.

• En los equipos orientados al público general no existe un mecanismo para enviar archivos manualmente y solicitar una revisión de reputación; la reputación se acumula por el historial de descargas
• Los administradores de TI de una empresa pueden enviar archivos a través del portal de Microsoft Security Intelligence. En la distribución interna o en equipos administrados, esto puede acelerar la obtención de confianza
• Si se sigue firmando con el mismo certificado, la reputación del propio certificado va creciendo, por lo que las versiones nuevas pueden mostrar la advertencia con menos frecuencia. Con archivos sin firmar, hay que volver a acumular reputación desde cero en cada actualización

En definitiva, lo realista es preparar la comunicación asumiendo que «la advertencia va a aparecer durante un tiempo» en el lanzamiento inicial, y seguir distribuyendo sin cambiar el certificado ni el nombre del editor.

11. Flujo de decisión

Al decidir el método de distribución, pensar en este orden reduce la indecisión.

flowchart TD
    accTitle: Flujo de decisión para el método de distribución
    accDescr: Diagrama de flujo que orienta la elección entre Microsoft Store/MSIX, un certificado OV o Azure Artifact Signing, y el diseño de distribución interna con Intune, GPO o App Control, según el público de destino y la disponibilidad de administración de equipos.
    A[Distribuir una aplicación de Windows] --> B{¿Es para el público general?}
    B -->|Sí| C{¿Se puede publicar en Microsoft Store?}
    C -->|Sí| D[Priorizar Store / MSIX]
    C -->|No| E[Firmar con certificado OV o Artifact Signing]
    B -->|No, uso interno| F{¿Hay administración de equipos?}
    F -->|Con Intune/GPO| G[Firma + distribución de certificados + auditoría de App Control]
    F -->|Sin administración| H[Origen de distribución fijo + firma + comunicación al usuario]
    E --> I[Asumir advertencia inicial de SmartScreen]
    G --> J[Implementación por etapas desde el modo de auditoría]
    H --> J

En la práctica, la primera opción se puede resumir así.

12. Lista de verificación mínima

Estos son los elementos a verificar antes de publicar y distribuir una aplicación de Windows.

Firma

• El EXE está firmado
• El DLL está firmado
• El MSI o el EXE del instalador está firmado
• El actualizador está firmado
• Se añadió marca de tiempo
• El archivo no se reescribió después de firmarlo
• Se verificó con signtool verify

Distribución

• Se definió la URL de distribución oficial
• La página de descarga muestra el nombre del editor
• Se muestran el número de versión y la fecha de publicación
• Se asume la posibilidad de que aparezca la advertencia inicial de SmartScreen
• Se evaluó si es posible publicar en Microsoft Store
• En caso de distribución fuera de la Store, se evaluó el certificado OV o Artifact Signing

Actualización

• Los archivos de actualización también están firmados
• En un actualizador propio, los metadatos están firmados
• Se verifican el hash, el tamaño y la versión
• En caso de fallo, el proceso se detiene en modo fail-closed
• Existe un procedimiento de rollback

Distribución interna

• Se verificó la presencia de Intune / GPO / App Control
• Se definió el método de distribución de certificados
• Se revisaron los eventos de bloqueo en modo de auditoría
• Se implementa por etapas separando los departamentos de destino
• Se verificó que no se vuelva a bloquear en cada actualización

13. Resumen

Crear una aplicación de Windows no es el final del trabajo: el archivo distribuido debe tener una forma «confiable» tanto para Windows como para el usuario y para la política corporativa.

Los puntos que conviene retener son estos.

• SmartScreen evalúa la reputación del archivo y del editor
• La firma de código es necesaria, pero no garantiza cero advertencias
• No se elige un certificado EV con el fin de evitar SmartScreen de inmediato
• En la distribución general, evaluar primero Microsoft Store / MSIX
• En la distribución fuera de la Store, usar un certificado OV o Artifact Signing y asumir advertencias iniciales
• En la distribución interna, revisar no solo SmartScreen, sino también Intune, GPO y App Control
• Diseñar el actualizador no como una función de distribución, sino como un límite de seguridad del producto

En una frase, se puede resumir así.

La distribución de una aplicación de Windows no consiste en «dónde colocar el archivo», sino en diseñar «cómo lograr que Windows confíe en ella».

Para seguir leyendo

• Guía para elegir el método de distribución de aplicaciones de Windows
• Introducción a ClickOnce: distribución, actualización y criterios de selección
• Diseño de seguridad de las actualizaciones automáticas
• Lista de verificación de seguridad mínima para el desarrollo de aplicaciones de Windows
• El límite entre necesitar o no privilegios de administrador en Windows
• Límites y práctica de compilar aplicaciones de Windows como binario único

Referencias

• Microsoft Learn: SmartScreen reputation for Windows app developers
• Microsoft Learn: Code signing options for Windows app developers
• Microsoft Learn: What is Artifact Signing? - Descripción general de Azure Artifact Signing (antes Trusted Signing) y su nombre oficial actual.
• Microsoft Learn: Sign your MSIX package - end-to-end guide
• Microsoft Learn: SignTool.exe
• Microsoft Learn: Deploying App Control for Business policies
• Microsoft Learn: Manage approved apps for Windows devices with App Control for Business policy and Managed Installers in Microsoft Intune

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Por qué aparece la advertencia «Windows protegió su PC»?

Aparece porque Microsoft Defender SmartScreen todavía no considera que ese archivo sea suficientemente confiable. SmartScreen no se limita a determinar si algo es un virus: analiza la reputación del editor, la reputación del hash del archivo, si existe firma y por qué canal se distribuye. Un archivo recién creado es, desde el punto de vista de Windows, «un archivo que se ve por primera vez», así que aunque esté firmado puede aparecer la advertencia mientras no se acumula reputación suficiente. Esto no significa que se haya determinado que es malware, pero sí significa que Windows todavía no lo considera suficientemente confiable.

¿La firma de código elimina la advertencia de SmartScreen?

No necesariamente. Lo que garantiza la firma de código son solo dos cosas: que el archivo fue firmado por el editor que se muestra y que no fue alterado después de la firma; no garantiza cero advertencias. Aunque el archivo esté firmado, puede seguir apareciendo la advertencia mientras la reputación del archivo o del editor no sea suficiente. Aun así, la firma de código es casi indispensable como base para la distribución, las actualizaciones, las auditorías y la adopción en empresas. Sin firma, en entornos corporativos el archivo puede ser bloqueado por App Control, EDR, Defender y herramientas similares.

¿Comprar un certificado EV evita la advertencia de SmartScreen desde la primera descarga?

Esa es una idea desactualizada. Según la explicación actual de Microsoft, el comportamiento por el que un certificado EV evitaba automáticamente la advertencia de SmartScreen en la primera descarga ya no existe, y hay que asumir que un archivo firmado con EV acumula reputación de la misma manera que uno firmado con un certificado OV. Tiene sentido usar EV cuando lo exigen requisitos de adquisición corporativa o la revisión de seguridad de un socio comercial, pero no se recomienda comprar un certificado EV con el único objetivo de evitar la advertencia de SmartScreen. Si ese es el objetivo, conviene reconsiderar primero el canal de distribución, el método de firma y si es posible distribuir a través de la Store.

¿Cómo se debería distribuir para reducir la advertencia de SmartScreen?

Si la distribución es amplia hacia el público general, conviene evaluar primero Microsoft Store / MSIX. Los paquetes MSIX enviados a la Store son refirmados por Microsoft, por lo que es el canal que suele resultar más estable en cuanto a SmartScreen. Si no se puede publicar en la Store, hay que firmar con un certificado OV o con Azure Artifact Signing, asumir que puede aparecer una advertencia inicial e informar a los usuarios de la URL de descarga oficial, el nombre del editor, la versión y el hash del archivo. En la distribución interna, además de la firma, hace falta diseñar el canal de distribución incluyendo Intune, GPO y App Control.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.