Normas del CBE: pruebe su app de banca móvil con sesión iniciada y antes de cada versión.
El CBE exige a bancos y proveedores de pago evaluar los sistemas de banca por internet y de pagos móviles al menos cada tres meses, realizar una prueba de penetración al menos una vez al año que cubra cada versión de la app móvil, y enviar al CBE el informe de prueba de penetración previo al lanzamiento sin debilidades de riesgo alto o medio. El marco de ciberseguridad financiera y la ley de protección de datos personales añaden obligaciones de gobernanza, notificación de incidentes y protección de datos. Ostorlab prueba su app y las API que la sustentan, con sesión iniciada, en cada versión.
- Evalúa la app móvil y las API que llama, en la versión que descargan sus clientes
- Prueba los códigos de dos factores, la reautenticación de transferencias de alto riesgo, el bloqueo y la expiración de sesiones con sus cuentas de prueba
- Comprueba la detección de root y jailbreak, la protección contra manipulación, las capturas de pantalla y los datos que la app deja en el teléfono
- Enumera los SDK y bibliotecas nativas de cada versión y los relaciona con vulnerabilidades conocidas
- A quién se aplica
- Bancos y proveedores y operadores de servicios de pago regulados por el CBE, y las apps móviles que ofrecen
- Fecha clave
- Normas de banca por internet aprobadas el 4 de noviembre de 2014; normas de servicios de pago móvil, tercera edición, abril de 2021; cumplimiento de la PDPL desde el 31 de octubre de 2026
- Objeto
- Evaluación de vulnerabilidades y pruebas de penetración, incluida cada versión de la app móvil, autenticación y endurecimiento de la app
- Referencia principal
- Marco de ciberseguridad financiera del CBE (EG-FinCSF) y las normas de servicios de pago del CBE
Los textos del CBE detrás de su canal móvil
Las normas de banca por internet y de pagos móviles fijan la base técnica, y el marco de ciberseguridad y la ley de protección de datos se han añadido después. Las fechas siguientes corresponden a los textos citados en esta página.
- 4 de noviembre de 2014
Normas de banca por internet
El consejo del CBE aprueba las normas que regulan la prestación de servicios bancarios por Internet, comunicadas a los bancos por circular el 9 de noviembre de 2014. Las normas cubren la autenticación, la gestión de contraseñas, el cifrado y la evaluación de seguridad de los sistemas de banca por internet.
- Abril de 2021
Normas de servicios de pago móvil
La tercera edición de las normas que regulan los servicios de pago móvil fija requisitos de autenticación y contraseñas, medidas de seguridad de las aplicaciones y un ciclo de evaluación de seguridad que debe incluir cada versión de la aplicación de pago móvil.
- 26 de octubre de 2021
Normas de la Instant Payment Network
El CBE publica las normas de la Instant Payment Network, con requisitos de cifrado, detección de riesgos del dispositivo, autenticación de dos factores y pruebas de penetración anuales cuyos informes se envían al CBE.
- Diciembre de 2021
Marco de ciberseguridad financiera
El CBE difunde la primera edición del marco de ciberseguridad financiera (EG-FinCSF), el marco sectorial para bancos y proveedores de pago, junto con EG-FinCIRT, el equipo de respuesta a incidentes del sector financiero.
- 1 de noviembre de 2025
Reglamento de la PDPL
El Decreto n.º 816 de 2025 publica el reglamento de la ley de protección de datos personales, en vigor al día siguiente. El período de gracia de un año termina el 31 de octubre de 2026, cuando se aplica plenamente.
- 23 de agosto de 2026
Normas de identidad financiera digital
El CBE publica las normas del sistema de identidad financiera digital usado para el KYC electrónico, que exigen revisar periódicamente las pruebas de infraestructura y ciberseguridad y una autoevaluación de ciberseguridad remitida al CBE.
Las normas del CBE, aplicadas a su app móvil
Para cada norma: qué dice el texto, qué supone para una app de banca móvil, cómo ayuda Ostorlab y qué sigue en sus manos. Los textos de banca por internet, pagos móviles e identidad digital están en árabe y se resumen aquí; las normas de la IPN están en inglés.
- Normas del CBE de banca por internet, 3-8-1 a 3-8-3; normas del CBE de servicios de pago móvil, 3-11-1 a 3-11-4 (texto en árabe)
Evaluar los sistemas de banca por internet y pagos móviles con un ciclo fijo
Qué dice el texto
Las normas del CBE exigen una evaluación periódica de la seguridad de todos los sistemas relacionados con los servicios de banca por internet y de pagos móviles, en el centro principal y en el centro de recuperación ante desastres. Las actividades mínimas son una evaluación de vulnerabilidades al menos cada tres meses, o tras un cambio fundamental del entorno operativo, y una prueba de penetración al menos una vez al año o antes de lanzar cualquier servicio vital nuevo. La evaluación de vulnerabilidades debe cubrir debilidades comunes como la inyección SQL, la elusión de la autenticación y el almacenamiento inseguro; los hallazgos deben corregirse y la corrección validarse con una nueva prueba. El alcance de las actividades de evaluación debe incluir cada versión de la aplicación de pago móvil disponible para los clientes del banco.
Qué supone para su app móvil
La app está explícitamente en el alcance, y no solo la versión probada hace un año: las normas dicen cada versión disponible para los clientes. Una evaluación trimestral y una prueba de penetración anual son el mínimo.
Cómo ayuda Ostorlab
Una prueba de penetración con agentes de IA prueba la app y sus API con sesión iniciada, en la versión que usted publica, con un exploit funcional que puede reproducir para cada hallazgo de un agente de IA. Mobile SAST, Mobile DAST y SCA se ejecutan desde su canal CI/CD en cada compilación, de modo que cada versión publicada en las tiendas se evalúa entre las rondas formales.
Qué sigue en sus manos
Definir el alcance de las evaluaciones, probar servidores, equipos de red y el centro de recuperación, y reportar los resultados internamente.
- Normas del CBE de la IPN, 7-3-3 y 7-3-4; normas del CBE de banca por internet, 4-5-1 (texto en árabe)
Enviar al CBE el informe de prueba de penetración previo al lanzamiento
Qué dice el texto
Un servicio nuevo no debe lanzarse antes de que el CBE haya recibido el informe de prueba de penetración del entorno de producción, que muestre que no hay debilidades de riesgo alto o medio. El banco debe obtener la aprobación del CBE para activar el servicio, y el informe debe presentarse dentro de los tres meses siguientes a su emisión. La prueba de penetración debe realizarla un proveedor externo independiente bajo acuerdo de confidencialidad, con un informe inicial y un plan de remediación firmados, la validación de las correcciones en los sistemas principal y de recuperación, y un informe final firmado remitido al CBE. El mismo proveedor no debe realizar más de dos pruebas de penetración consecutivas.
Qué supone para su app móvil
Es una puerta de salida a producción, no un rito anual. La evidencia tiene un destinatario fuera de su institución, así que los hallazgos y las re-pruebas deben documentarse y ser reproducibles.
Cómo ayuda Ostorlab
Ostorlab genera evidencia por hallazgo que puede adjuntar a la presentación: un exploit reproducible para cada hallazgo de un agente de IA y solicitudes y respuestas para los hallazgos de API, con resultados de re-prueba tras la corrección.
Qué sigue en sus manos
Elegir y contratar al proveedor independiente, firmar los informes, probar el centro de recuperación y la presentación al CBE.
- Normas del CBE de servicios de pago móvil, 3-4 y 3-5 (texto en árabe)
Usar dos factores y reautenticar las operaciones de alto riesgo
Qué dice el texto
La autenticación de los servicios de pago móvil debe combinar dos de tres elementos: algo que el usuario sabe, algo que posee, como una firma digital o contraseñas de un solo uso de dispositivos o aplicaciones de token de seguridad, o algo que es, como la biometría. Las actividades de alto riesgo, incluidas las órdenes de pago a varios beneficiarios, las transferencias por encima del límite máximo y los cambios en los datos de contacto del cliente, deben reautenticarse con dos medios, y las contraseñas de un solo uso para personas físicas no deben entregarse automáticamente por SMS o correo electrónico para esas operaciones. Las contraseñas de un solo uso deben tener al menos seis caracteres y ser válidas durante un máximo de 90 segundos; los PIN deben tener al menos seis dígitos, preferiblemente ocho, sin valores fáciles; y el servicio debe bloquear el acceso tras un número definido de intentos fallidos, sin revelar si el nombre de usuario o la contraseña eran incorrectos.
Fuente:Normas del CBE de servicios de pago móvil, 3-4 y 3-5 (texto en árabe)
Qué supone para su app móvil
Los controles son lo bastante concretos para probarlos: qué flujos exigen el segundo factor, de dónde viene el código de un solo uso, cuánto vive y qué ocurre tras los intentos fallidos.
Cómo ayuda Ostorlab
Las pruebas autenticadas completan códigos de un solo uso por SMS, correo o TOTP con sus cuentas de prueba, prueban la aplicación efectiva de la MFA y los flujos de autenticación reforzada en acciones de alto riesgo, y comprueban el bloqueo, la enumeración de usuarios y la reutilización de códigos de un solo uso en la app y las API que la sustentan.
Qué sigue en sus manos
Elegir los métodos de autenticación, la calibración biométrica y la clasificación de riesgo de cada tipo de transacción.
- Normas del CBE de servicios de pago móvil, 3-9; normas del CBE de la IPN, 7-1-9 y 7-1-10
Endurecer la app frente a dispositivos comprometidos y manipulación
Qué dice el texto
Las normas de pago móvil esperan que la app detecte dispositivos de riesgo y resista la manipulación. Las medidas incluyen detección suficiente de que el teléfono no tiene root ni jailbreak, protección contra la ingeniería inversa como la ofuscación del código, protección contra capturas de pantalla automáticas de software espía en el mismo dispositivo, bloquear que la app almacene o muestre contraseñas introducidas antes, y cierre de sesión automático tras un período de inactividad. Cuando una versión nueva corrige un problema de seguridad, el banco debe exigir a los clientes que la instalen antes de poder usar la app. La app debe publicarse desde la cuenta oficial del banco en las tiendas, con la marca correcta, y los bancos deben buscar copias falsas en las tiendas para limitar el malware que ataca las credenciales de los clientes.
Fuente:Normas del CBE de servicios de pago móvil, 3-9; normas del CBE de la IPN, 7-1-9 y 7-1-10
Qué supone para su app móvil
Cada punto es un comportamiento probable de la versión que instalan sus clientes, no una declaración de políticas: ¿la app se detiene o avisa, puede eludirse la comprobación y sigue funcionando una versión antigua?
Cómo ayuda Ostorlab
Mobile Shielding Scan ejecuta la app en entornos con root y jailbreak, intenta eludir la detección de root y jailbreak, la protección contra manipulación y la instrumentación, y muestra si la app bloquea el flujo, se niega a arrancar o sigue funcionando.
Qué sigue en sus manos
Elegir el producto de blindaje, redactar la política de actualización forzosa y ejecutar el proceso de vigilancia de apps falsas.
- Normas del CBE de servicios de pago móvil, 3-5, 3-8 y 3-9-8; normas del CBE de la IPN, 7-1-2, 7-1-6 y 7-1-8
Cifrar los datos en tránsito y guardar poco en el dispositivo
Qué dice el texto
Los datos almacenados en la memoria interna del teléfono deben limitarse, y todo lo que se conserve por una necesidad real debe protegerse. Los datos enviados por la red móvil deben cifrarse en la capa de aplicación, para que los PIN y las contraseñas no queden expuestos en ninguna etapa intermedia entre la app y el servidor de alojamiento, donde se verifican. Las contraseñas nunca deben procesarse, enviarse ni almacenarse en texto claro, y el cifrado debe usar métodos fuertes o una longitud de clave adecuada, con las claves protegidas durante todo su ciclo de vida. Las normas de la IPN añaden que el proceso debe cifrarse desde el canal de pago hasta los servidores que ejecutan la orden de pago, y que debe usarse cifrado reconocido internacionalmente.
Qué supone para su app móvil
Lo que la app escribe en archivos, cachés, registros y capturas de pantalla, y cómo se protege el tráfico de extremo a extremo, son cosas que un evaluador puede demostrar en lugar de suponer.
Cómo ayuda Ostorlab
Ostorlab busca tokens, contraseñas y datos personales en el almacenamiento local, las cachés, los registros y las capturas de pantalla, comprueba la protección del transporte y encuentra claves, tokens y credenciales que quedan en el paquete de la app.
Qué sigue en sus manos
La clasificación de datos, la gestión de claves y la elección y configuración de la pila de cifrado.
- Normas del CBE de banca por internet, 3-6-13 a 3-6-15; normas del CBE de servicios de pago móvil, 3-8-6, 3-9-2, 3-9-3 y 3-9-4 (texto en árabe)
Probar que la autenticación no puede eludirse y aplicar las reglas en el servidor
Qué dice el texto
Las normas de banca por internet exigen a los bancos probar que la autenticación no puede eludirse ni omitirse para entrar en el sistema, definir procedimientos estrictos de identidad y autorización para sistemas y bases de datos, diseñar los procesos del sistema de forma segura y mantener pistas de auditoría. Las normas de pago móvil añaden una validación completa de las entradas, incluidos los datos introducidos por el usuario y las consultas de base de datos que el usuario pueda intentar ejecutar, realizada en los servidores de red, y exigen que las comprobaciones de autorización del usuario y las reglas de transferencia se ejecuten en el servidor, en los sistemas centrales del banco, antes de completar la operación. Los sistemas deben funcionar con los privilegios mínimos necesarios, no deben usar contraseñas conocidas ni predeterminadas, y los mensajes de error mostrados a los clientes no deben revelar detalles del sistema.
Qué supone para su app móvil
Una comprobación en el lado del cliente no es un control. La app puede modificarse, así que el servidor debe imponer la autenticación, la autorización y las reglas de negocio de una transferencia.
Cómo ayuda Ostorlab
Ostorlab modifica la app y reproduce llamadas para probar si la autenticación puede omitirse y si la autorización se aplica en el servidor, buscando controles de autorización rotos a nivel de objeto y función (BOLA, BFLA, IDOR), parámetros manipulados y abuso de lógica de negocio.
Qué sigue en sus manos
Las normas de diseño y código seguro, la revisión de código y su plataforma de registro y pistas de auditoría.
- Normas del CBE de servicios de pago móvil, 3-9-10 a 3-9-12; normas del CBE de la IPN, 2-2-2-5, 2-2-2-8, 7-1-11 y 7-2-1
Gestionar los componentes de terceros y el canal de las tiendas
Qué dice el texto
Las normas de pago móvil exigen controles de seguridad adecuados cuando se usan bibliotecas de terceros o componentes de aplicación ya hechos para construir la app de pago, y dicen que la app no debe exponer ningún servicio de una aplicación de terceros que se ejecute en el mismo dispositivo, ni de ninguna otra fuente externa, salvo los sistemas centrales del propio banco. Las normas de la IPN exigen que el banco conozca a los terceros de los que depende y obtenga la aprobación del CBE antes de externalizar servicios. Las aplicaciones de la Instant Payment Network deben someterse a múltiples pruebas antes de funcionar, y los sistemas del banco deben protegerse con la infraestructura adecuada, incluidos sistemas de detección y prevención de intrusiones y cortafuegos.
Qué supone para su app móvil
Cada SDK incluido en la app es código de terceros con acceso a la red, y un servicio nuevo solo entra en producción después de probarse y, cuando se exige, de ser aprobado por el CBE.
Cómo ayuda Ostorlab
SCA y SBOM enumeran los SDK y bibliotecas nativas de cada versión con sus versiones y su ubicación en el paquete, y los relacionan con vulnerabilidades conocidas, versión tras versión. Ostorlab vigila las versiones publicadas en las tiendas sin activación manual.
Qué sigue en sus manos
La diligencia debida sobre terceros, los contratos, las aprobaciones del CBE para externalización y el inventario de activos.
- Normas del CBE de servicios de pago móvil, 2-2, 2-3, 3-10 y 3-12 (texto en árabe); normas del CBE de identidad financiera digital, 23 de agosto de 2026; páginas de ciberseguridad del CBE
Ejecutar la gobernanza ciber y notificar incidentes al CBE
Qué dice el texto
El consejo y la alta dirección son responsables de una estrategia de seguridad clara, una política de seguridad de la información aprobada, la clasificación de riesgos de los servicios de pago móvil y una revisión continua. Los bancos deben vigilar los sistemas y la infraestructura de forma proactiva, 24 horas al día, siete días a la semana, registrar violaciones de seguridad, brechas y debilidades sospechadas, proteger las pistas de auditoría frente a manipulaciones y revisar las alertas de seguridad. Los procedimientos de incidentes deben cubrir la notificación y el tratamiento inmediatos, la contención, la recogida de evidencia y el escalado. El responsable de cumplimiento debe notificar al CBE incidentes como el phishing y el robo de credenciales, el acceso no autorizado a sistemas, las operaciones destructivas de datos, la interrupción prolongada o deliberada del servicio y el fraude interno. El CBE difundió el marco de ciberseguridad financiera (EG-FinCSF) y gestiona EG-FinCIRT, el equipo de respuesta a incidentes del sector, como canal de notificación de incidentes ciber. Para los servicios de KYC electrónico, los bancos deben revisar periódicamente las pruebas de infraestructura y ciberseguridad, evaluar la madurez y preparación ciber, realizar una autoevaluación de ciberseguridad alineada con el marco del CBE, hacer que la verifique una parte independiente y enviar los resultados al CBE.
Qué supone para su app móvil
La gobernanza y la vigilancia siguen en el banco, pero la app forma parte del patrimonio vigilado, y es donde se hacen visibles las señales de riesgo del dispositivo y los inicios de sesión sospechosos.
Cómo ayuda Ostorlab
Ostorlab prueba los controles de la app y sus API y aporta evidencia por hallazgo, que alimenta el trabajo de aseguramiento y autoevaluación. No realiza la vigilancia del SOC, la respuesta a incidentes ni las notificaciones al CBE y EG-FinCIRT.
Qué sigue en sus manos
El programa de seguridad, la vigilancia 24x7, la respuesta a incidentes, las notificaciones al CBE y EG-FinCIRT y la autoevaluación de eKYC.
- Ley n.º 194 de 2020 del Banco Central y del sistema bancario, artículos 140, 142, 197, 198 y 231 (texto en árabe)
Mantener la confidencialidad de los datos de clientes según la ley bancaria
Qué dice el texto
La ley del Banco Central y del sistema bancario hace estrictamente confidenciales todos los datos de los clientes, incluidas cuentas, depósitos, objetos en custodia y transacciones. No pueden divulgarse sin el consentimiento escrito del cliente o una orden judicial o arbitral, y la obligación continúa tras el fin de la relación bancaria y tras el cese de un empleado en su puesto. Los operadores y proveedores de sistemas de pago deben garantizar una protección adecuada de sus sistemas electrónicos frente a ataques informáticos, accesos no autorizados, manipulación de datos y brechas de confidencialidad o privacidad, y deben notificar al CBE cualquier incidente que afecte a la continuidad del servicio o al funcionamiento del sistema. Las infracciones de los artículos de confidencialidad se castigan con prisión de al menos un año y multa, o con una de esas penas.
Qué supone para su app móvil
La confidencialidad es un deber legal con sanciones penales, y la app móvil es uno de los lugares donde los datos de los clientes están más expuestos.
Cómo ayuda Ostorlab
Ostorlab encuentra datos personales y credenciales que la app deja en el dispositivo o envía en claro, y prueba si las API detrás de la app permiten que un cliente llegue a los datos de otro.
Qué sigue en sus manos
La interpretación jurídica, los procedimientos de consentimiento y divulgación, y la prevención de pérdida de datos.
- Ley n.º 151 de 2020 de protección de datos personales, artículos 4, 7, 8, 14, 15, 16, 17 y 38; reglamento, Decreto n.º 816 de 2025 (texto en árabe)
Cumplir la ley de protección de datos personales y su reglamento
Qué dice el texto
La ley de protección de datos personales exige a los responsables obtener el consentimiento u otra base legítima, verificar que los datos son exactos y pertinentes, aplicar las medidas técnicas y organizativas necesarias para protegerlos, mantener un registro de tratamiento y borrar los datos cuando termina la finalidad. Los responsables y encargados deben designar y registrar a un delegado de protección de datos, y notificar al Centro de Protección de Datos Personales cualquier brecha de datos personales en un plazo de 72 horas, y a las personas afectadas en tres días hábiles. Se prohíbe transferir datos personales al extranjero salvo que el destino ofrezca un nivel de protección no inferior al de la ley y la transferencia esté autorizada o licenciada por el Centro. El marketing electrónico directo requiere consentimiento previo y un mecanismo de exclusión. El reglamento, Decreto n.º 816 de 2025, establece las categorías de licencias y permisos, las medidas de seguridad durante el tratamiento y los procedimientos de notificación de brechas. Un período de gracia de un año termina el 31 de octubre de 2026, tras el cual se aplican plenamente las sanciones de la ley.
Qué supone para su app móvil
La app recopila, almacena y transmite datos personales, así que los flujos de consentimiento, la minimización, la retención, la notificación de brechas y la elección de la región de alojamiento forman parte de su diseño.
Cómo ayuda Ostorlab
Ostorlab muestra qué datos personales salen de la app, dónde se almacenan o se guardan en caché en el dispositivo y cómo viajan al backend, de modo que las medidas técnicas y la respuesta a brechas se verifican en lugar de suponerse.
Qué sigue en sus manos
Las licencias y permisos del Centro, el registro del delegado de protección de datos, los avisos de consentimiento, las aprobaciones de transferencia transfronteriza y el procedimiento de notificación de brechas.
Resumen de textos públicos del CBE y textos egipcios, consultados el 27 de septiembre de 2026. Los textos de banca por internet, pagos móviles e identidad digital están en árabe y se resumen aquí; las normas de la IPN están en inglés. El marco de ciberseguridad financiera se difunde a las instituciones y no se publica como documento público independiente, por lo que solo se describe a partir del material público del CBE. Esta página no constituye asesoramiento jurídico.
Las normas del CBE, control por control
Los controles a los que apuntan los textos del CBE, cómo los prueba Ostorlab en su app y sus API, y la evidencia que puede conservar.
| Control | Cómo ayuda Ostorlab | Evidencia que conserva |
|---|---|---|
| Evaluación de vulnerabilidades de los sistemas de banca por internet y pagos móvilesNormas de banca por internet 3-8-2; normas de pago móvil 3-11-2 | Mobile DAST ejecuta la app y la ejercita desde su canal, y las pruebas de API interceptan el tráfico incluso con TLS pinning y sondean debilidades comunes como la inyección y la autorización rota. Detalles | Resultados de escaneo por ejecución, con solicitudes y respuestas para cada hallazgo |
| Prueba de penetración anual que cubra cada versión de la appNormas de banca por internet 3-8-3; normas de pago móvil 3-11-3 y 3-11-4 | Pentest con agentes de IA de la app y sus API, con sesión iniciada, en la versión que usted publica. Detalles | Un exploit funcional que puede reproducir para cada hallazgo de un agente de IA, y un mapa de cobertura |
| Prueba de producción previa al lanzamiento sin debilidades de riesgo alto o medioNormas de banca por internet 4-5-1; normas de la IPN 7-3-3 | Prueba la app y las API que llama con sesión iniciada y vuelve a probar tras las correcciones, de modo que los hallazgos y los cierres quedan documentados candidato a producción tras candidato. Detalles | Hallazgos iniciales, estado de remediación y resultados de re-prueba para cada candidato a producción |
| Autenticación de dos factores y reautenticación de operaciones de alto riesgoNormas de pago móvil 3-4 | Inicia sesión con códigos de un solo uso y prueba la aplicación efectiva de la MFA y los flujos de autenticación reforzada, incluidas las manipulaciones que intentan los atacantes. Detalles | Hallazgos sobre los flujos de inicio de sesión y autenticación reforzada, con pasos de reproducción |
| Bloqueo tras intentos fallidos, sin enumeración de usuarios, y expiración de sesiónNormas de pago móvil 3-5-1 y 3-9-16 | Prueba el bloqueo tras fallos consecutivos, la enumeración de usuarios, el cierre automático por inactividad y la invalidación de sesiones. Detalles | Hallazgos sobre sesiones y tokens, con registros de solicitudes y respuestas |
| Detección de root y jailbreak, protección contra manipulación y capturas de pantallaNormas de pago móvil 3-9-17 a 3-9-19 | Ejecuta la app en entornos con root y jailbreak e intenta eludir la detección, la instrumentación y el bloqueo de capturas de pantalla. Detalles | Puntuación de endurecimiento y evidencia de elusión por cada protección que falló |
| Datos que quedan en el dispositivo y cifrado de la capa de aplicaciónNormas de pago móvil 3-8-1, 3-8-2, 3-9-8 y 3-9-14 | Mobile SAST analiza el código de almacenamiento, criptografía y registro del binario, en la app y sus SDK integrados. Detalles | Hallazgos con contexto del código descompilado y evidencia del sistema de archivos sobre qué se escribió, dónde y cuándo |
| Componentes de terceros, SDK y canal de las tiendasNormas de pago móvil 3-9-10 a 3-9-12 | Identifica por huella las bibliotecas compiladas estáticamente y las relaciona con vulnerabilidades conocidas, versión tras versión. Detalles | Vulnerabilidades identificadas con recomendaciones de actualización o sustitución, y cierre seguido entre versiones |
| Autorización en el servidor y validación de entradasNormas de pago móvil 3-8-6 y 3-9-2 | Intercepta el tráfico de la app incluso con TLS pinning y prueba la autorización, el uso indebido de tokens y abusos como la enumeración y el replay. Detalles | Solicitudes y respuestas para cada hallazgo de API |
| Credenciales y claves en el paquete de la appNormas de pago móvil 3-5-1 y 3-9-3; normas de la IPN 7-1-2 | Encuentra claves de API, tokens y credenciales en el paquete de la app y valida si funcionan. Detalles | Secretos validados, con los permisos y servicios que exponen |
Ostorlab prueba controles en la app y sus API. El programa de seguridad, la vigilancia 24x7, la respuesta a incidentes y las notificaciones al CBE y EG-FinCIRT, las pruebas de penetración de servidores y redes, la recuperación ante desastres, la gobernanza y la seguridad física siguen en sus equipos.
Controles del CBE que probar en su app móvil
Una lista práctica para equipos de seguridad y cumplimiento, basada en las normas del CBE de banca por internet, pagos móviles e identidad digital, y en la ley de protección de datos personales.
Evaluación trimestral
Incluya los sistemas de banca por internet y pagos móviles, y cada versión publicada en las tiendas, en el alcance de una evaluación de vulnerabilidades al menos cada tres meses y de una prueba de penetración al menos una vez al año.
Informe previo al lanzamiento
Exija una prueba de penetración en producción sin debilidades de riesgo alto o medio antes de lanzar un servicio nuevo, y envíe el informe al CBE dentro de los tres meses siguientes a su emisión.
Dos factores en los flujos correctos
Compruebe que las acciones de alto riesgo exigen reautenticación con dos medios, que las contraseñas de un solo uso para personas físicas no llegan por SMS o correo en esas acciones, y que los códigos caducan en 90 segundos.
Endurecer la versión
Pruebe la detección de root y jailbreak, la ofuscación, el bloqueo de capturas de pantalla y el comportamiento de actualización forzosa frente a una versión modificada y hooks de ejecución.
Datos en el teléfono
Busque PIN, contraseñas, tokens y datos personales en el almacenamiento, las cachés, los registros y las capturas de pantalla, y compruebe el cifrado de la capa de aplicación y el manejo de claves.
Componentes y tiendas
Mantenga una lista versionada de los SDK y bibliotecas de cada versión, verifique los controles de seguridad de los componentes de terceros y vigile las tiendas en busca de copias falsas de la app.
Gobernanza e incidentes
Confirme que la vigilancia 24x7 y las pistas de auditoría están en marcha, y que la lista de incidentes que notificar al CBE y EG-FinCIRT está integrada en sus procedimientos.
Datos personales
Registre al delegado de protección de datos, prepare la notificación de brechas en 72 horas, revise las transferencias transfronterizas frente a las reglas de licencia de la PDPL y planifique la fecha límite del 31 de octubre de 2026.
Una lista sugerida, no una plantilla del CBE. Esto no constituye asesoramiento jurídico.
Las capacidades detrás de esta página
Cada una tiene su propia página con los detalles.
- Mobile Agentic Deep ScanLos agentes de IA realizan el pentest de la versión publicada en cada release, con un exploit funcional que puede reproducir para cada hallazgo de un agente de IA.Más información
- Pruebas autenticadasPruebe el inicio de sesión, los códigos de un solo uso y la autenticación reforzada con sus cuentas de prueba.Más información
- Pruebas de API y backendIntercepte el tráfico de la app incluso con TLS pinning y pruebe las API y los backends detrás de cuentas y pagos.Más información
- Mobile SASTAnálisis estático basado en el binario de archivos APK, AAB e IPA, con análisis de propagación (taint) en toda la app y sus SDK integrados.Más información
- SCA y SBOMDetecte dependencias vulnerables, incluidas las bibliotecas nativas compiladas estáticamente, y haga un seguimiento de su cierre versión tras versión.Más información
- Mobile Shielding ScanPruebe en tiempo de ejecución la detección de root y jailbreak, la protección contra manipulación y el pinning, y vea qué protecciones resistieron y cuáles se evadieron.Más información
- Su propia clave de IAEjecute los escaneos con agentes de IA con la clave de su proveedor de IA y un límite de gasto por escaneo, según sus políticas internas.Más información
- Escaneo on-premisesEscanee apps de preproducción, API y repositorios detrás de su firewall o VPN, en una infraestructura que usted controla.Más información
Bancos y fintechs confían en nosotros, entre ellos
Fuentes
Los textos oficiales en los que se basa esta página, consultados el 27 de septiembre de 2026.
- Rules regulating the provision of banking services via the InternetCBE, aprobadas por el consejo el 4 de noviembre de 2014 y comunicadas por circular del 9 de noviembre de 2014. Texto en árabe. Partes sobre autenticación (3-2), gestión de contraseñas (3-3), cifrado (3-5), evaluación de seguridad (3-8) y licencias (4-5)
- Rules regulating the provision of mobile payment services, third editionCBE, abril de 2021. Texto en árabe. Autenticación (3-4), gestión de contraseñas (3-5), confidencialidad e integridad (3-8), seguridad de aplicaciones (3-9), vigilancia de seguridad (3-10), evaluación de seguridad (3-11) y respuesta a incidentes (3-12)
- Rules regulating services for the Instant Payment Network inside the Arab Republic of EgyptCBE, octubre de 2021, comunicadas por circular del 26 de octubre de 2021. Texto en inglés. Confidencialidad e integridad de la información (7-1), infraestructura y vigilancia (7-2), evaluación de seguridad incluidas las pruebas de penetración (7-3) y respuesta a incidentes (7-4)
- Rules of the digital financial identity system for the eKYC of banks' customersCBE, circular del 23 de agosto de 2026. Texto en árabe. Verificación electrónica de identidad y alta remota, revisión anual del dispositivo de gestión de riesgos y una autoevaluación de ciberseguridad alineada con el marco del CBE, verificada de forma independiente y remitida al CBE
- Central Bank and Banking System Law No. 194 of 2020PDF oficial del CBE, texto en árabe. Confidencialidad de los datos de clientes (artículos 140 y 142), operadores y proveedores de sistemas de pago, incluida la protección de sistemas electrónicos y la notificación de incidentes al CBE (artículos 197 y 198), y sanciones por divulgación (artículo 231). Se utilizó una traducción al inglés para la lectura
- Personal Data Protection Law No. 151 of 2020Boletín Oficial, 2020. Texto en árabe. Obligaciones del responsable (artículo 4), notificación de brechas en 72 horas (artículo 7), delegado de protección de datos (artículo 8), transferencias transfronterizas (artículos 14 a 16), marketing directo (artículo 17) y sanciones (artículo 38). Se utilizó una traducción al inglés para la lectura
- Executive Regulations of the Personal Data Protection Law, Decree No. 816 of 2025Boletín Oficial, número 244 (suplemento A), 1 de noviembre de 2025, en vigor el 2 de noviembre de 2025. Licencias y permisos, medidas de seguridad durante el tratamiento, registro del delegado de protección de datos y procedimientos de notificación de brechas. El período de gracia de un año termina el 31 de octubre de 2026. Se utilizó una traducción al inglés para la lectura
- Financial Cybersecurity Framework (EG-FinCSF) and cybersecurity pagesCBE. La primera edición del marco sectorial se difundió en diciembre de 2021, y el CBE gestiona EG-FinCIRT, el equipo de respuesta a incidentes informáticos del sector financiero. El marco se difunde a las instituciones y no se publica como documento público independiente, por lo que esta página solo lo describe a partir del material público del CBE
Preguntas frecuentes
Respuestas claras sobre cobertura, configuración y cómo llegan los resultados a su equipo.
¿No encuentra su respuesta? Reserve una demo o contáctenos.
Pruebe su app de banca móvil contra las normas del CBE
Empiece con un escaneo gratuito de su app desde la tienda, o reserve una demo para ejecutar con nuestro equipo pruebas con sesión iniciada y de shielding de su app y sus API.