¿Por qué el PPAP es un problema en la seguridad del correo electrónico? ¿Cuál es la forma correcta de hacerlo?

«¿Es realmente seguro enviar un ZIP protegido con contraseña y, después, enviar la contraseña en otro correo?». Esta pregunta sigue apareciendo con frecuencia. A primera vista parece seguro porque hay cifrado de por medio, pero en la práctica ahí está la trampa.

El llamado PPAP es débil como medida contra la interceptación, insuficiente también como medida contra los envíos erróneos y, además, tiende a interferir con la inspección en el trayecto del correo, por lo que en la seguridad del correo electrónico actual es un método difícil de recomendar.¹²³⁴

En este artículo, basándonos en materiales oficiales y fuentes primarias disponibles hasta abril de 2026, repasamos los problemas del PPAP y cuál es la forma natural de sustituirlo en la práctica.^12345678910

Público objetivo y prerrequisitos de este artículo

Terminología usada en este artículo

Antes de continuar, resumimos en una línea cada uno de los términos que aparecerán sin explicación a partir del capítulo 3.

1. Ante todo, la conclusión

Dejar el PPAP no significa dejar de cifrar. Lo que hay que abandonar es el diseño de «cifrar el archivo adjunto en un ZIP y enviar después la contraseña por el mismo canal de correo».

En su lugar, conviene pensar en estas tres cosas.

1. Para el correo de negocio habitual, se parte de una protección del canal de comunicación como TLS o STARTTLS.⁷¹⁰
2. Si se necesita autenticidad o cifrado del propio correo, se usa un mecanismo como S/MIME.³⁵⁶
3. Para la entrega de archivos confidenciales, se opta por descargas con autenticación o uso compartido con control de acceso, en lugar de adjuntos.⁴⁸⁹

En definitiva, lo importante es no intentar resolver todos los problemas del correo con la contraseña de un ZIP.

2. Qué es el PPAP, para empezar

El PPAP al que nos referimos aquí, en general, designa el siguiente flujo.

1. Convertir el archivo en un ZIP protegido con contraseña
2. Enviar el ZIP en un primer correo
3. Enviar la contraseña en un segundo correo

Esta práctica suele entenderse como «segura porque no se envía en texto plano». Sin embargo, en la práctica, lo que realmente protege es bastante limitado.

No es tan infalible como parece: el problema del PPAP es que, aunque da la impresión de ser seguro, en realidad no protege lo que realmente importa.

3. Por qué el PPAP es un problema

3.1 Es débil como medida contra la interceptación

La Oficina del Gabinete (内閣府) ha señalado que el método de enviar automáticamente la contraseña por el mismo canal que el archivo ZIP no es apropiado.¹ Lo importante es que no basta con haber cifrado el archivo: si el diseño no incluye también cómo se entrega la clave, el sentido de cifrar se diluye.

Esto se debe a que, si solo se envía después al mismo entorno de correo, al mismo buzón y al mismo destinatario, quien puede ver el ZIP y quien puede ver la contraseña acaban siendo, en la práctica, las mismas personas. Con esto queda solamente el hecho de que «se está cifrando», pero la confidencialidad real no es tan sólida.

3.2 Es insuficiente como medida contra los envíos erróneos

Hay quien considera el PPAP una medida contra los envíos erróneos, pero también es débil en ese punto.

En las respuestas modelo del examen de Ingeniero de Información Aplicada de IPA, se señala como problema del PPAP que, si el correo principal se envía por error, la contraseña de descifrado también llega al mismo destinatario equivocado.³ En un documento de la Agencia Digital (デジタル庁) también se plantea, en el mismo sentido, que «enviarla como un correo aparte al mismo destinatario equivale a enviarla a la misma persona, por lo que no funciona como control».⁴

En otras palabras, si tras enviar el ZIP al destinatario equivocado se termina enviando también la contraseña por costumbre, el incidente queda consumado tal cual. Lo que realmente se necesita es un método de entrega que permita verificar el destinatario, aprobar el envío, revisarlo antes de enviarlo y revocar o recuperar el contenido después de enviarlo.

3.3 Dificulta la inspección antimalware

Este es un punto que no se puede pasar por alto entre los problemas del PPAP.

IPA ha advertido, respecto a los correos de ataque de Emotet que adjuntan un ZIP protegido con contraseña, que, como el adjunto está cifrado, es muy probable que eluda la detección y la cuarentena de los productos de seguridad presentes en el trayecto de entrega del correo y llegue a manos del destinatario.²

Aunque quien envía crea que «al cifrarlo lo hizo seguro», desde el punto de vista del receptor o de los servidores intermedios, se convierte en un archivo adjunto difícil de inspeccionar por dentro. También en este sentido, no puede decirse que el PPAP sea un método compatible con las defensas actuales del correo electrónico.

3.4 No garantiza la autenticidad ni el control de acceso

El PPAP no demuestra que el remitente sea quien dice ser. Tampoco cuenta apenas con controles de acceso como saber quién descargó el archivo y cuándo, poder revocarlo después, o diferenciar permisos por destinatario.

Por otro lado, IPA trata el correo con firma electrónica como S/MIME, lo que también se conecta, en este contexto, como alternativa al PPAP.⁵⁶ Además, en los materiales de seguridad web de IPA se establece que un sitio web que maneja información no pública necesita funciones de autenticación y control de acceso.⁸

Si se consideran ambos puntos juntos, la respuesta es bastante clara.

• Si se busca autenticidad del correo o detección de alteraciones, S/MIME
• Si se busca gestionar permisos de visualización de archivos o su revocación, descarga con autenticación

El envío separado de la contraseña de un ZIP no responde con claridad a ninguna de las dos cosas.

4. La forma correcta es «separar según el objetivo»

La necesidad de «enviar algo de forma segura» no es, en realidad, una sola cosa. Si no se separa esto, se termina intentando resolverlo todo con el PPAP y el diseño se desmorona.

4.1 El correo de negocio habitual

Para el correo de negocio habitual, lo primero es partir de una protección del canal de comunicación como TLS o STARTTLS.⁷¹⁰ Sobre esa base, si se necesita autenticidad del remitente, detección de alteraciones o cifrado del propio cuerpo del correo, lo lógico es considerar S/MIME.³⁵⁶

4.2 La entrega de archivos confidenciales

Se quiere entregar el archivo únicamente a la persona destinataria, controlar los permisos de visualización y poder revocarlo después. Para este requisito, es más natural recurrir a descargas con autenticación o a un uso compartido con control de acceso, en lugar de adjuntos.⁴⁸⁹

Por ejemplo, requisitos como los siguientes son más fáciles de gestionar desde el lado web que mediante adjuntos.

• Se puede descargar después de iniciar sesión
• Se puede convertir en un enlace con caducidad
• Se pueden diferenciar los permisos por destinatario
• Se puede conservar un historial si es necesario

Antes de decidir «qué comprar», definir las condiciones que hay que cumplir

Si se empieza por los nombres de los productos, la comparación deja de ser posible, así que primero enumeramos las condiciones. La diferencia con el PPAP se resume en estas seis filas.

Pasar de la izquierda a la derecha de esta tabla es, en esencia, lo que significa «dejar el PPAP». Dicho de otro modo, si una alternativa no cumple estas seis filas, tiene poco sentido migrar a ella.

En muchos casos, ya se puede hacer con lo que ya se tiene contratado

Antes de comprar un producto nuevo, lo primero es comprobar hasta dónde se puede llegar con el contrato actual. En los casos más representativos, la situación es la siguiente.

El orden de prioridad es: primero, «uso compartido especificando a un destinatario concreto»; «enlace con contraseña» es la segunda opción. El enlace con contraseña se usa solo cuando el destinatario no puede disponer de una cuenta, y esa contraseña se comunica por un canal distinto del correo, como el teléfono o un SMS. Si aquí se termina enviando por el mismo canal de correo, aunque se crea haber sustituido el PPAP, se vuelve a caer en la misma estructura.

Lo mínimo indispensable si se construye por cuenta propia

Aunque se construya una función de descarga en el propio sitio de la empresa, lo que hay que tener en cuenta no cambia.

1. Un medio para identificar al destinatario Emitir una cuenta para la persona a la que se entrega el archivo, o emitir para cada caso una URL de un solo uso con un token.
2. Caducidad Dar una fecha de caducidad tanto a la URL como al token. Cuando caduque, en lugar de mostrar «no se encuentra», se debe devolver de forma explícita el mensaje «ha caducado».
3. La operación de revocación Es necesario que la persona a cargo de la operación pueda invalidarlo de inmediato desde el panel de administración. Sin esto, aunque se detecte un envío erróneo, no se puede hacer nada.
4. Registro de accesos Dejar constancia de cuándo, desde qué IP y qué archivo se obtuvo. La diferencia clave está en si, cuando ocurre un incidente, se puede responder a la pregunta de si el archivo «llegó a manos de alguien o no».
5. Proteger el lugar donde se almacena el archivo Es decir, evitar que cualquiera que conozca la URL pueda obtenerlo. IPA también establece que un sitio web que maneja información no pública necesita funciones de autenticación y control de acceso.⁸
6. El tratamiento del lado de la subida También al recibir archivos del destinatario conviene apoyarse en el mismo mecanismo. Crear un formulario exclusivo para recepción es más seguro que seguir aceptando adjuntos de correo.

De estos seis puntos, el 2 y el 3 son la diferencia decisiva con el PPAP. Ya sea que se construya o se compre, lo que carezca de esto no sirve como alternativa.

4.3 Cuando de todas formas es necesario un adjunto

Hay situaciones en las que, por circunstancias del destinatario, no queda más remedio que usar un adjunto. En ese caso, tal como señala la Oficina del Gabinete, lo mínimo indispensable es transmitir el archivo y la contraseña por canales completamente distintos.¹

Sin embargo, esto no es una solución definitiva, sino una medida provisional. En lugar de fijarla como la operación estándar de cada vez, es mejor pensarla partiendo de que, en el futuro, se migrará hacia el uso compartido con autenticación.

5. Procedimiento de sustitución en pymes

Cuando una pyme deja el PPAP, es más eficaz aclarar primero la clasificación que introducir desde el principio un sistema grande.

5.1 Lo primero que hay que detener

• Cifrado automático en ZIP
• Envío automático de la contraseña por separado dentro del mismo canal de correo
• La regla uniforme de que «todos los archivos importantes van por PPAP»

5.2 Lo siguiente que hay que decidir

• Qué se puede enviar por correo normal
• Qué se debe prohibir como adjunto
• Qué se debe derivar a descarga con autenticación
• Cómo definir el procedimiento de aprobación para los casos excepcionales en que se adjunta

5.3 La idea de una configuración mínima

Al principio, basta con separar en estos dos sistemas.

1. Correo normal
   • Comunicaciones de trabajo
   • S/MIME cuando sea necesario
2. Archivos confidenciales
   • Descarga con autenticación
   • Configuración de permisos
   • Uso compartido con caducidad

Si esto queda ambiguo, en la práctica es fácil que se termine volviendo a «PPAP, por si acaso».

6. Flujo de decisión

flowchart TD
    accTitle: Flujo de decisión para elegir entre correo normal, S/MIME, descarga con autenticación o adjunto cifrado
    accDescr: Diagrama que muestra cómo decidir el método de entrega según si el archivo es confidencial y si el destinatario puede iniciar sesión, terminando en correo normal, descarga con autenticación o, como último recurso, un adjunto cifrado con contraseña enviada por separado.
    A[¿Qué se quiere entregar al destinatario?] --> B{¿Es un archivo de alta confidencialidad?}
    B -- No --> C[Correo de negocio habitual]
    C --> C1[Enviar partiendo de TLS / STARTTLS]
    C --> C2[Si importa la autenticidad o el cifrado, usar S/MIME]

    B -- Sí --> D{¿El destinatario puede iniciar sesión para recibirlo?}
    D -- Sí --> E[Descarga con autenticación / uso compartido con control de acceso]
    E --> E1[Configurar permisos, caducidad y revocación según sea necesario]

    D -- No --> F{¿Es indispensable un adjunto?}
    F -- Sí --> G[Archivo cifrado + contraseña manual por otro canal]
    F -- No --> E

Para los entornos donde no se muestre el diagrama, presentamos la misma decisión también en forma de tabla. Léala de arriba hacia abajo y tome la conclusión de la primera fila que corresponda.

Lo importante en este diagrama es no colocar al PPAP como una solución intermedia universal. El correo electrónico y la entrega de archivos son más fáciles de diseñar si se consideran por separado.

7. Malentendidos frecuentes

7.1 «Como el ZIP está cifrado, es seguro»

Aunque esté cifrado, no es suficiente si la forma de entregar la clave es débil. Además, un ZIP protegido con contraseña puede dificultar la inspección en el trayecto.¹²

7.2 «Basta con enviarlo en otro correo»

Enviarlo después al mismo destinatario y por el mismo canal de correo no constituye un control sólido.¹⁴

7.3 «Si se deja el PPAP, ya no se podrá adjuntar nada»

No es así. Solo se trata de usar según el caso el correo normal, S/MIME, la descarga con autenticación y, en casos excepcionales, la contraseña por otro canal.

7.4 «S/MIME es para grandes empresas y no es realista»

Hay que tener en cuenta el nivel de compatibilidad de la otra parte, pero al menos es más coherente que el PPAP respecto a qué se quiere proteger. Además, para los destinatarios con los que S/MIME no encaja, existe la otra opción de la descarga con autenticación.

8. Resumen

El problema del PPAP está en que, aunque se cifra, es fácil tener la sensación de que se ha vuelto seguro. En la práctica, quedan los siguientes problemas:

• El envío por separado dentro del mismo canal de correo tiene una confidencialidad débil
• Es insuficiente como medida contra los envíos erróneos
• Un ZIP protegido con contraseña dificulta la inspección en el trayecto
• No se puede garantizar la autenticidad del remitente ni el control de acceso

Estos problemas persisten.¹²³⁴

Por lo tanto, lo que hay que hacer no es prolongar la vida del PPAP cambiándolo un poco. Es proteger el correo como correo y diseñar la entrega de archivos como entrega de archivos.

Resumido en una frase, sería así.

Dejar el PPAP no significa dejar de cifrar, sino abandonar un control equivocado y sustituirlo por el control adecuado para el objetivo.

Artículos relacionados

• Cómo diseñar el envío masivo de correo para pymes sin atarse a un servicio concreto
• Cómo conectar los artículos con las páginas de servicio - fundamentos del diseño de enlaces internos
• Cómo crear páginas de servicio - procedimiento de organización para el ámbito técnico y B2B

Referencias

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.

¿Qué es el PPAP?

Es la práctica de convertir un archivo en un ZIP protegido con contraseña, enviarlo en un primer correo y enviar la contraseña en un segundo correo. Como no se envía en texto plano, parece seguro, pero en la práctica lo que realmente protege es bastante limitado. La confidencialidad en el canal de comunicación es débil, resulta insuficiente como medida contra los envíos erróneos, y tampoco garantiza la autenticidad del remitente ni el control de acceso.

¿Por qué es peligroso el PPAP?

Hay cuatro problemas principales. Primero, aunque la contraseña se envíe por separado, si se hace por el mismo canal de correo, quien puede ver el ZIP y quien puede ver la contraseña acaban siendo prácticamente las mismas personas, por lo que es una medida débil contra la interceptación. Segundo, si el destinatario es incorrecto, la contraseña de descifrado también llega a esa misma persona equivocada, lo que lo hace insuficiente como medida contra los envíos erróneos. Tercero, como el ZIP protegido con contraseña está cifrado, tiende a eludir la detección y la cuarentena de los productos de seguridad que inspeccionan el correo en tránsito, y existen casos reales de abuso en correos de ataque como los de Emotet. Y cuarto, no garantiza la autenticidad del remitente ni el control de acceso.

Si dejamos de usar el PPAP, ¿qué deberíamos usar en su lugar?

Lo básico es separar el problema en tres según el objetivo. Para el correo de negocio habitual, se parte de una protección del canal de comunicación como TLS o STARTTLS, y si se necesita autenticidad o cifrado del propio correo, se usa S/MIME. Para la entrega de archivos confidenciales, conviene inclinarse hacia descargas con autenticación o uso compartido con control de acceso en lugar de adjuntos, ya que así se puede gestionar permisos, enlaces con caducidad y revocación de acceso. Lo importante es no intentar resolver todos los problemas del correo con la contraseña de un ZIP.

¿Qué hacer si, de todas formas, es necesario enviar el archivo como adjunto?

Si, por circunstancias del destinatario, no queda más remedio que usar un adjunto, el mínimo indispensable es transmitir el archivo cifrado y la contraseña por canales completamente distintos. Sin embargo, esto no es una solución definitiva, sino una medida provisional. Es más seguro no fijarla como operación estándar para cada caso, sino pensarla partiendo de que, en el futuro, se migrará hacia el uso compartido con autenticación.

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.