Règles de la HKMA : évaluez votre application bancaire mobile avant et après chaque version.
Le module TM-E-1 du manuel de supervision de la HKMA demande aux banques de réaliser une évaluation indépendante rigoureuse avant de lancer ou de modifier un canal de banque électronique, et de confier à des parties qualifiées des tests d'intrusion de la banque en ligne et des services fournis via Internet ou un réseau sans fil au moins une fois par an, en plus de l'authentification à deux facteurs pour les transactions à risque élevé. Depuis 2025, les mesures E-Banking Security ABCD poussent les banques à faire passer la connexion et les transactions à risque élevé à l'authentification in-app via un appareil lié, plutôt qu'aux mots de passe à usage unique par SMS. Ostorlab teste votre application et les API qui la sous-tendent, derrière la connexion, à chaque version.
- Évalue l'application mobile et les API qu'elle appelle, sur le build que téléchargent vos clients
- Teste la connexion, les codes à usage unique, l'authentification renforcée, la liaison d'appareil et la gestion des sessions avec vos comptes de test
- Recense les SDK et bibliothèques natives de chaque version et les rapproche des vulnérabilités connues
- Prouve chaque résultat par un exploit rejouable ou par les requêtes et réponses à l'appui
- Qui est concerné
- Toutes les institutions autorisées (IA) supervisées par la HKMA. Les IA désignées opérateurs d'infrastructures critiques relèvent en plus d'obligations légales au titre du PCICSO
- Dates clés
- TM-E-1 V.4 publié le 25 octobre 2024 ; E-Banking Security ABCD depuis le 25 août 2025 ; le PCICSO en vigueur depuis le 1er janvier 2026
- Objet
- Évaluation indépendante et tests d'intrusion annuels, contrôles des applications mobiles, authentification à deux facteurs et in-app, et tests de résilience C-RAF 2.0
- Texte de référence
- Manuel de supervision de la HKMA, module TM-E-1 « Risk Management of E-banking » (V.4)
Les textes de la HKMA qui encadrent votre canal mobile
TM-E-1 et les circulaires sur la banque électronique complètent les modules du manuel de supervision consacrés au risque cyber et à la résilience opérationnelle, et depuis 2026 le PCICSO. Les dates ci-dessous concernent les textes cités sur cette page.
- 3 novembre 2020
Cybersecurity Fortification Initiative 2.0
La HKMA fait évoluer son cadre d'évaluation de la cyber-résilience et ajoute des exigences de Blue Team aux tests de simulation d'attaque cyber guidés par le renseignement (iCAST). La CFI 2.0 prend effet le 1er janvier 2021, avec des évaluations échelonnées sur trois groupes d'IA.
- 31 mai 2022
OR-2 Résilience opérationnelle
Le module OR-2 pose le cadre : identifier les opérations critiques, fixer une tolérance aux perturbations et tester des scénarios graves mais plausibles, y compris des défaillances chez un tiers ou dans sa chaîne d'approvisionnement.
- 25 octobre 2024
TM-E-1 V.4
Le module actuel sur la gestion des risques de la banque électronique est publié comme ligne directrice statutaire au titre de l'article 7(3) de la Banking Ordinance : évaluation indépendante avant lancement, tests d'intrusion annuels, 2FA pour les transactions à risque élevé et contrôles spécifiques pour la banque en ligne accédée depuis un appareil mobile.
- 29 novembre 2024
Supervision du risque cyber TM-C-1
La HKMA publie son approche de supervision de la gestion du risque cyber, qui confirme le C-RAF et l'iCAST comme outils centraux pour évaluer et relever la maturité de défense cyber des IA.
- 14 avril 2025
E-Banking Security ABC
La HKMA attend des clients équipés d'une application bancaire mobile qu'ils s'authentifient in-app via un appareil lié, par défaut, pour les connexions à la banque en ligne et les transactions à risque élevé, au lieu des mots de passe à usage unique par SMS. La liaison et la nouvelle liaison d'appareil passent à la reconnaissance faciale, avec un calendrier de mise en œuvre du deuxième au quatrième trimestre 2025.
- 25 août 2025
E-Banking Security ABCD
La détection des deepfakes s'ajoute au dispositif, avec effet immédiat. L'annexe énonce de bonnes pratiques : renforcer la sécurité des appareils, randomiser les tests de vivacité, ajouter des analyses d'images et surveiller les traces numériques anormales.
- 1er janvier 2026
Entrée en vigueur du PCICSO
La Protection of Critical Infrastructures (Computer Systems) Ordinance (Cap. 653) entre en vigueur et impose trois catégories d'obligations légales aux opérateurs d'infrastructures critiques désignés.
- 2 juin 2026
Code de pratique sectoriel pour les IA
Le code de pratique du Monetary Authority pour les IA désignées opérateurs d'infrastructures critiques entre en vigueur : il fixe le socle du plan de gestion de la sécurité, de l'évaluation annuelle des risques avec évaluation de vulnérabilité et test d'intrusion, et de l'audit biennal.
Les règles de la HKMA sur la banque électronique, appliquées à votre application mobile
Pour chaque règle : ce que dit le texte, ce que cela implique pour une application bancaire mobile, comment Ostorlab vous aide et ce qui reste du ressort de votre équipe. Les numéros de section et les formulations suivent les documents anglais de la HKMA.
- SPM TM-E-1, 3.3.1 à 3.3.3
Évaluation indépendante et tests d'intrusion annuels
Ce que dit le texte
Dans le cadre de la gouvernance des risques de la banque électronique, la direction générale doit veiller à ce qu'une évaluation indépendante rigoureuse soit réalisée avant le lancement de tout nouveau canal électronique ou d'une amélioration majeure d'un service existant, en vérifiant que le service respecte les orientations applicables et que des contrôles de gestion des risques suffisants sont réellement en place. Si la politique d'évaluation indépendante n'inclut pas de tests d'intrusion, des tests réguliers doivent être réalisés par des parties indépendantes qualifiées, en évaluant au minimum la banque en ligne de l'IA et tout service financier fourni via Internet ou un réseau sans fil, annuellement. Une évaluation formelle des risques est également attendue au moins une fois par an.
Source :SPM TM-E-1, 3.3.1 à 3.3.3
Ce que cela implique pour votre application mobile
Une application bancaire mobile est un canal de banque électronique. L'évaluation indépendante, le test d'intrusion annuel et la revue annuelle des vulnérabilités émergentes doivent tous la couvrir, y compris les API qu'elle appelle.
Comment Ostorlab vous aide
Ostorlab réalise un pentest par agents IA de l'application et de ses API derrière la connexion, un Mobile SAST sur l'APK, l'AAB ou l'IPA, et des tests de protection à l'exécution, rejouables à la demande, pour produire les mêmes preuves avant le lancement, chaque année et à chaque version.
Ce qui reste de votre ressort
Le choix des évaluateurs, la réalisation de l'évaluation formelle des risques et la résolution des problèmes matériels avant le lancement.
- SPM TM-E-1, 7.1.1 à 7.1.4
Évaluer le canal mobile et ses risques spécifiques
Ce que dit le texte
La banque en ligne accédée depuis un appareil mobile comporte des risques spécifiques : vulnérabilités des plateformes mobiles, logiciels malveillants ou applications frauduleuses qui capturent des informations sensibles, redirigent ou masquent les notifications ou les mots de passe à usage unique, ou incitent les clients à effectuer des transactions non autorisées, perte ou vol des appareils, et sensibilisation moindre des clients à la sécurité. Les IA doivent identifier et évaluer ces risques et mettre en place les mesures de sécurité correspondantes, mener des programmes de sensibilisation pour les appareils mobiles, et rechercher en continu les fausses applications bancaires pour en informer les clients. Lorsque les clients reçoivent ou génèrent des mots de passe à usage unique sur le même appareil que celui utilisé pour la banque, des contrôles de sécurité supplémentaires sont requis.
Source :SPM TM-E-1, 7.1.1 à 7.1.4
Ce que cela implique pour votre application mobile
L'application elle-même est dans le périmètre, pas seulement le backend. Les logiciels de superposition, l'interception de notifications, l'altération et les fausses applications sont des menaces propres au mobile que vos contrôles doivent traiter.
Comment Ostorlab vous aide
Mobile SAST inspecte le binaire et ses SDK intégrés, Mobile Shielding Scan teste à l'exécution la détection du root et du jailbreak, l'anti-altération et le pinning, et le pentest par agents IA éprouve l'application et ses API comme le ferait un fraudeur.
Ce qui reste de votre ressort
La surveillance des fausses applications dans les stores, la sensibilisation des clients et votre politique pour les appareils qui reçoivent aussi les mots de passe à usage unique.
- SPM TM-E-1, 4.1.1 à 4.1.8 ; circulaire « New Anti-Digital Fraud Measures: E-Banking Security ABC », 14 avril 2025, annexe
Authentification à deux facteurs et authentification in-app par défaut
Ce que dit le texte
Pour la banque en ligne, les IA doivent exiger une authentification à deux facteurs au moins une fois pour authentifier l'identité du client à chaque session de connexion avant d'effectuer des transactions à risque élevé, qui incluent les virements vers des bénéficiaires tiers non enregistrés, certains paiements de factures et les transferts d'avantages ou de points de récompense à des tiers. Si une transaction à risque élevé est jugée suspecte, par exemple un virement de montant élevé peu après une liaison d'appareil, une confirmation supplémentaire est attendue. Depuis 2025, la HKMA attend des clients équipés d'une application bancaire mobile qu'ils authentifient les connexions à la banque en ligne et les transactions à risque élevé via un appareil lié, par défaut, plutôt que par SMS. La liaison et la nouvelle liaison d'appareil doivent utiliser la reconnaissance faciale ou des méthodes aussi strictes, avec une période de réflexion et une surveillance renforcée de la fraude pour les transactions à risque élevé lorsque les mots de passe à usage unique par SMS restent autorisés.
Ce que cela implique pour votre application mobile
Le second facteur doit être imposé par le serveur à chaque étape clé, et l'authentification par appareil lié change la manière dont l'application enregistre et fait confiance à un appareil. Ce sont des comportements que vous pouvez tester.
Comment Ostorlab vous aide
Les tests authentifiés couvrent la connexion et la déconnexion, les codes à usage unique, les parcours d'authentification renforcée et in-app, ainsi que les appels d'API qui les sous-tendent, avec vos comptes de test.
Ce qui reste de votre ressort
Le déploiement de l'authentification par appareil lié et de la reconnaissance faciale, les règles de période de réflexion et la communication aux clients.
- SPM TM-E-1, 4.4.1 à 4.4.3 et 5.3.3 ; circulaire « Enhancement to security of electronic banking services », 31 octobre 2023, point 8
Contrôles de session et outils d'activité du compte
Ce que dit le texte
Pour la banque en ligne, les IA doivent mettre en place des contrôles de gestion de session efficaces qui interdisent les connexions simultanées à un compte de banque électronique, sauf besoin réel, et journaliser les données clés des tentatives de connexion supplémentaires, comme l'adresse IP, le type d'appareil et la localisation. Les clients doivent pouvoir consulter et surveiller l'activité du compte, y compris la date et l'heure de connexion, la localisation et les informations sur l'appareil, et rechercher les activités à risque élevé sur une période raisonnablement longue, normalement au moins 90 jours. Les IA doivent aussi offrir un canal accessible pour demander de l'aide et un mécanisme pour suspendre rapidement un compte de banque électronique, avec une réactivation soumise à une authentification stricte.
Ce que cela implique pour votre application mobile
La gestion des connexions simultanées, les délais d'expiration, l'invalidation des jetons, les écrans de consultation d'activité et le parcours de suspension sont des comportements testables, et les journaux qu'ils produisent sont des preuves.
Comment Ostorlab vous aide
Ostorlab teste la connexion et la déconnexion, le renouvellement des jetons, les délais d'expiration et l'invalidation des sessions, y compris les tentatives de connexion simultanée, et vérifie ce que l'application et ses API écrivent dans le stockage, les caches et les journaux.
Ce qui reste de votre ressort
Les outils d'activité destinés aux clients, le mécanisme de suspension et la conservation des journaux.
- SPM TM-E-1, 5.2.1 et 5.4.1 à 5.4.3 ; SPM TM-G-1, 3.4.1 et 5.3.1
Évaluation des vulnérabilités, veille sur les menaces et gestion des correctifs
Ce que dit le texte
Les IA doivent mettre en place un processus systématique de veille sur les menaces pesant sur leur infrastructure Internet, leurs systèmes applicatifs et leurs autres composants, et utiliser des outils automatisés, complétés par des techniques manuelles si nécessaire, pour réaliser des évaluations périodiques de vulnérabilité de l'infrastructure Internet et des systèmes de banque en ligne, en traitant les résultats selon une approche fondée sur les risques. Les procédures de gestion des correctifs doivent couvrir les systèmes et les composants d'infrastructure. TM-G-1 attend des responsabilités claires pour que les correctifs et mises à jour de sécurité soient identifiés, évalués, testés et appliqués en temps voulu, ainsi qu'un inventaire du matériel et des installations pour contrôler et suivre le matériel et les logiciels achetés et loués.
Source :SPM TM-E-1, 5.2.1 et 5.4.1 à 5.4.3 ; SPM TM-G-1, 3.4.1 et 5.3.1
Ce que cela implique pour votre application mobile
Les SDK et bibliothèques natives intégrés à votre application sont des logiciels que vous livrez à vos clients, et la liste des composants vulnérables peut changer à chaque version.
Comment Ostorlab vous aide
SCA identifie les bibliothèques compilées statiquement et les rapproche des vulnérabilités connues, version après version. Les résultats sont classés critiques, élevés, moyens ou faibles, suivis sous forme de tickets dans la plateforme ou dans Jira et ServiceNow, et retestés une fois le correctif publié.
Ce qui reste de votre ressort
L'analyse de l'infrastructure, l'application des correctifs sur les serveurs et appareils, et les décisions d'acceptation des risques.
- SPM TM-E-1, 5.3.1 et 5.3.2 ; code de pratique sectoriel du PCICSO, 6.2.22
Développement sécurisé et revue de code source
Ce que dit le texte
Les IA doivent maintenir un niveau adéquat de sécurité des systèmes applicatifs de leur banque en ligne, y compris les applications, couvrant au moins la conception et le développement, les tests et la mise en œuvre, en s'appuyant sur les bonnes pratiques du secteur. Avant de lancer un système de banque en ligne ou des modifications, une revue adéquate du code source doit être réalisée pour identifier les non-conformités aux standards de sécurité applicative, le code susceptible de créer des menaces ou des failles, et tout code malveillant. La revue doit être menée par une partie disposant de l'expertise nécessaire et indépendante des développeurs. Le code sectoriel du PCICSO ajoute un processus de développement sécurisé et la protection du code source pour les systèmes informatiques critiques.
Source :SPM TM-E-1, 5.3.1 et 5.3.2 ; code de pratique sectoriel du PCICSO, 6.2.22
Ce que cela implique pour votre application mobile
La revue doit avoir lieu avant la mise en production et couvrir aussi les composants tiers qui se retrouvent dans le bundle de l'application.
Comment Ostorlab vous aide
Mobile SAST analyse le binaire APK, AAB ou IPA avec analyse de propagation (taint) sur l'application et ses SDK intégrés, pour détecter les problèmes de code même lorsque seul le build du store est disponible.
Ce qui reste de votre ressort
Les normes de développement sécurisé, la propriété du code et la revue manuelle de votre propre code source.
- Circulaire « Managing cyber risk associated with third-party service providers », 21 décembre 2023 ; circulaire « Risk Associated with Third-party IT Solutions », 27 septembre 2024
Gérer le risque cyber des services et logiciels tiers
Ce que dit le texte
La HKMA a partagé un ensemble de bonnes pratiques pour gérer le risque cyber lié aux prestataires de services tiers : gouvernance, vérifications préalables, contrôles contractuels et surveillance continue. Après un incident informatique mondial causé par la mise à jour défectueuse d'un fournisseur de solutions de cybersécurité, la HKMA a rappelé aux IA de gérer les dépendances tierces : tester les mises à jour avant déploiement, garder la maîtrise des mises à jour automatiques sans choix de l'utilisateur, et résister à la défaillance de solutions informatiques tierces, y compris lorsque des services critiques en dépendent.
Ce que cela implique pour votre application mobile
Une application bancaire mobile est assemblée à partir de SDK et de services tiers. Leur cycle de mise à jour et leurs modes de défaillance font partie de votre risque, pas seulement de celui de votre fournisseur.
Comment Ostorlab vous aide
Ostorlab recense les SDK et bibliothèques natives de chaque version avec leurs versions et leur emplacement dans le bundle, et montre ce que l'application et ses SDK échangent avec les backends sur le réseau. Les retests montrent si un correctif fournisseur a réellement fermé le problème.
Ce qui reste de votre ressort
Les contrats, les vérifications préalables, le suivi des fournisseurs et la décision de conserver ou remplacer un prestataire.
- SPM TM-C-1, 3.5 ; circulaire « Cybersecurity Fortification Initiative 2.0 », 3 novembre 2020 ; SPM OR-2, 4.3 et 7 ; circulaire « Strengthening Cyber Resilience amid Artificial Intelligence-Empowered Cyber Threats », 2 juin 2026
C-RAF 2.0, iCAST et tests de scénarios
Ce que dit le texte
Dans le cadre de la Cybersecurity Fortification Initiative, les IA s'auto-évaluent via le Cyber Resilience Assessment Framework : une évaluation du risque inhérent, une évaluation de maturité et, pour les IA dont le risque inhérent est moyen ou élevé, des tests de simulation d'attaque cyber guidés par le renseignement (iCAST) qui simulent des attaques réelles. Le C-RAF 2.0 a ajouté des exigences de Blue Team à l'iCAST, pour mesurer les fonctions de détection, de réponse et de rétablissement. TM-C-1 confirme le C-RAF comme outil de la HKMA pour vérifier que la maturité de défense cyber est proportionnée au risque. OR-2 attend par ailleurs des tests de scénarios de perturbations graves mais plausibles, y compris des défaillances chez un tiers ou dans sa chaîne d'approvisionnement. En juin 2026, la HKMA a demandé aux IA de vérifier que leurs contrôles restent adaptés face à des attaques assistées par l'IA de pointe et d'examiner la cyber-résilience de leurs prestataires tiers.
Ce que cela implique pour votre application mobile
L'iCAST est un exercice à l'échelle de l'institution, mené par des parties qualifiées, et non un scan d'application mobile. Des problèmes applicatifs et d'API déjà corrigés constituent la base qui évite d'y traîner des faiblesses connues.
Comment Ostorlab vous aide
Ostorlab ne réalise pas d'iCAST ni d'autres exercices de red team. Il clôt et reteste les points relatifs à l'application et aux API de votre plan de remédiation, pour que les évaluations plus larges partent d'une base plus propre.
Ce qui reste de votre ressort
Le cadrage et la conduite du C-RAF et de l'iCAST avec des évaluateurs qualifiés, l'exercice de Blue Team et les tests de scénarios de résilience opérationnelle.
- Code de pratique sectoriel du PCICSO, 2 juin 2026, 6.3.4 à 6.3.7 et 6.4 ; PCICSO (Cap. 653), articles 24 et 25
PCICSO : évaluation des risques, test d'intrusion et audit légaux
Ce que dit le texte
Depuis le 1er janvier 2026, la Protection of Critical Infrastructures (Computer Systems) Ordinance impose des obligations légales aux opérateurs désignés, et le Monetary Authority a publié un code de pratique sectoriel pour les IA qu'il désigne opérateurs d'infrastructures critiques. L'évaluation des risques liés à la sécurité des systèmes informatiques doit couvrir toutes les applications, hôtes et équipements réseau des systèmes informatiques critiques, et comprendre une évaluation de vulnérabilité et un test d'intrusion. Le test d'intrusion doit être mené du point de vue d'un attaquant potentiel ou à partir du renseignement sur les menaces, et couvrir la sécurité réseau, la sécurité des logiciels système, la sécurité des applications côté client et côté serveur. La première évaluation est due dans les 12 mois suivant la désignation, puis au moins une fois tous les 12 mois, avec un audit indépendant au moins une fois tous les 24 mois. Les rapports doivent présenter chaque constat avec sa priorité et un plan de traitement avec délais et responsables.
Ce que cela implique pour votre application mobile
La sécurité des applications côté client est explicitement citée : l'application mobile est donc dans le périmètre du test légal, et chaque constat a besoin de preuves et d'un plan de traitement suivi.
Comment Ostorlab vous aide
Ostorlab teste l'application et ses API et produit des preuves par constat : exploits rejouables, journaux de requêtes et réponses, inventaires de composants et résultats de retest que vous pouvez joindre au rapport d'évaluation.
Ce qui reste de votre ressort
La désignation de l'évaluateur qualifié et de l'auditeur indépendant, les tests réseau et d'infrastructure, et la soumission des rapports.
- SPM TM-E-1, 4.3.1, 4.4.5 et 5.1.1 ; Personal Data (Privacy) Ordinance (Cap. 486), principe de protection des données 4
Protéger les données des clients sur l'appareil et en transit
Ce que dit le texte
Les IA doivent utiliser un chiffrement fort, sûr et internationalement reconnu pour protéger les informations des clients transmises sur des réseaux externes et les informations hautement sensibles comme les identifiants de connexion stockés, avec de bonnes pratiques de gestion des clés. Les clients doivent être avertis de leur obligation de prendre des précautions raisonnables pour protéger leurs appareils et leurs facteurs d'authentification. Le manuel rappelle aux IA la nécessité de respecter la Personal Data (Privacy) Ordinance, qui impose aux utilisateurs de données de prendre toutes les mesures praticables pour protéger les données personnelles contre tout accès, traitement, effacement, perte ou usage non autorisé ou accidentel.
Ce que cela implique pour votre application mobile
Les jetons, identifiants et données personnelles ne devraient pas rester en clair dans le stockage de l'application, les caches, les journaux ou les captures d'écran, et la protection du transport doit tenir face à une attaque.
Comment Ostorlab vous aide
Ostorlab recherche les jetons de session et les données personnelles dans le stockage local, les caches, les journaux et les captures d'écran, vérifie la protection du transport et le contournement du pinning, et détecte les secrets et identifiants dans le package de l'application.
Ce qui reste de votre ressort
La classification des données, la gestion des clés, les mentions d'information, la conservation et la gestion des violations.
Synthèse de textes publics de la HKMA et du code sectoriel du PCICSO, vérifiés le 27 septembre 2026. Les numéros de section et les formulations suivent les documents anglais. Cette page ne constitue pas un avis juridique.
Règles de la HKMA et PCICSO, contrôle par contrôle
Les contrôles visés par les textes de la HKMA, la manière dont Ostorlab les teste dans votre application et ses API, et les preuves que vous pouvez conserver.
| Contrôle | Comment Ostorlab vous aide | Preuves conservées |
|---|---|---|
| Évaluation indépendante et tests d'intrusion annuelsTM-E-1 3.3 | Pentest par agents IA de l'application et de ses API, derrière la connexion, sur la version que vous livrez. Détails | Un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA, et une heatmap de couverture |
| Évaluation du canal mobile et protections à l'exécutionTM-E-1 7.1 | SAST sur le binaire et tests de protection à l'exécution : root, jailbreak, altération et pinning. Détails | Résultats par version sur les composants et les protections, avec les contournements constatés |
| 2FA, authentification in-app et liaison d'appareilTM-E-1 4.1 ; circulaire ABC, annexe | Se connecte avec des codes à usage unique et des appareils liés et teste les parcours d'authentification renforcée, y compris comment les contourner ou les rejouer. Détails | Résultats sur les parcours de connexion, d'authentification renforcée et de liaison, avec étapes de reproduction |
| Contrôles de session et connexions simultanéesTM-E-1 5.3.3 ; circulaire du 31 octobre 2023 | Teste la connexion et la déconnexion, le renouvellement des jetons, les délais d'expiration, l'invalidation des sessions et les tentatives de connexion simultanée. Détails | Résultats sur les sessions et les jetons, avec journaux des requêtes et réponses |
| Composants vulnérables et délais de correctionTM-E-1 5.4 ; TM-G-1 3.4.1 | Identifie par empreinte les bibliothèques compilées statiquement, y compris les SDK natifs, et les associe aux vulnérabilités connues. Détails | Vulnérabilités identifiées avec recommandations de mise à niveau ou de remplacement, et résolution suivie d'une version à l'autre |
| Développement sécurisé et revue de code sourceTM-E-1 5.3.1, 5.3.2 | Mobile SAST avec analyse de propagation (taint) sur l'application et ses SDK intégrés, sur l'APK, l'AAB ou l'IPA. Détails | Résultats au niveau du code, avec leur emplacement dans le binaire et le chemin des données |
| Identifiants intégrés aux applications et aux APITM-E-1 4.1.1 ; CoP 6.2.22 | Détecte les clés d'API, jetons et identifiants dans le package de l'application et vérifie s'ils sont fonctionnels. Détails | Secrets validés, avec les permissions et les services qu'ils exposent |
| Données des clients sur l'appareil et en transitTM-E-1 4.3.1, 4.4.5, 5.1.1 ; PDPO | Recherche les jetons et les données personnelles dans le stockage, les caches, les journaux et les captures d'écran, et vérifie la protection du transport. Détails | Preuves sur le système de fichiers montrant ce qui a été écrit, où et quand |
| Preuves pour l'évaluation et le test d'intrusion du PCICSOCoP sectoriel 6.3, 6.4 | Teste l'application et les API, suit chaque résultat jusqu'à sa clôture et reteste, pour que votre évaluateur puisse réutiliser les preuves. Détails | Historique des tickets et résultats de retest par résultat, prêts pour le plan de traitement |
| Préparation au C-RAF et à l'iCASTTM-C-1 3.5 ; CFI 2.0 | Ostorlab ne réalise pas d'iCAST. Il clôt et reteste les points relatifs à l'application et aux API de votre plan de remédiation. | Résultats de retest des points applicatifs et API avant l'exercice |
Ostorlab teste les contrôles de l'application et de ses API. La surveillance SOC, la réponse aux incidents et leur signalement, les exercices, l'iCAST et les autres tests red team, les sauvegardes et la reprise, la gouvernance et la sécurité physique restent du ressort de vos équipes.
Les contrôles de la HKMA à tester dans votre application mobile
Une liste pratique pour les équipes sécurité et risque des systèmes, fondée sur TM-E-1, les circulaires sur la banque électronique et le code sectoriel du PCICSO.
Évaluation indépendante
Intégrez l'application mobile, ses API et la revue préalable au lancement au périmètre de l'évaluation indépendante, et gardez le test d'intrusion annuel au calendrier.
Menaces propres au mobile
Testez à chaque version le root et le jailbreak, la superposition et l'altération, l'interception de notifications, la capture d'écran et la détection de fausses applications.
Authentification in-app
Vérifiez que l'authentification par appareil lié est imposée par le serveur pour la connexion et les transactions à risque élevé, et que tout repli par SMS reçoit la période de réflexion et la surveillance attendues par les circulaires.
Liaison d'appareil
Testez les parcours de liaison et de nouvelle liaison, y compris les étapes de reconnaissance faciale, les tentatives de rejeu et les contrôles contournés.
Sessions
Contrôlez le refus des connexions simultanées, les délais d'expiration, l'invalidation des jetons, et l'historique d'activité et les outils de suspension visibles par les clients.
Composants et délais
Tenez une liste versionnée des SDK et bibliothèques de chaque version, et fixez des délais de correction selon la gravité.
Tiers
Cartographiez ce que reçoit chaque SDK et backend tiers, et retestez les correctifs fournisseurs au lieu de leur faire confiance.
Signaler, retester et conserver les preuves
Suivez les résultats jusqu'à leur clôture, conservez les résultats de retest et réutilisez-les dans les rapports d'évaluation et plans de traitement du PCICSO.
Une liste indicative, et non un modèle de la HKMA. Ceci ne constitue pas un avis juridique.
Les capacités associées à cette page
Chacune a sa propre page détaillée.
- Mobile Agentic Deep ScanDes agents IA pentestent la version publiée à chaque release, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA.En savoir plus
- Tests authentifiésTestez la connexion, les codes à usage unique, l'authentification renforcée et in-app avec vos comptes de test.En savoir plus
- Tests des API et du backendInterceptez le trafic de l'application même avec TLS pinning, puis testez les API et backends derrière les comptes et les paiements.En savoir plus
- Mobile SASTAnalyse statique des binaires APK, AAB et IPA, avec analyse de propagation (taint) sur l'application et ses SDK intégrés.En savoir plus
- SCA et SBOMDétectez les dépendances vulnérables, y compris les bibliothèques natives compilées statiquement, et suivez leur résolution version après version.En savoir plus
- Mobile Shielding ScanTestez à l'exécution la détection du root et du jailbreak, l'anti-altération et le pinning, et voyez quelles protections ont tenu et lesquelles ont été contournées.En savoir plus
- Votre propre clé IALancez les scans par agents IA avec la clé de votre fournisseur d'IA et un plafond de dépense par scan, pour respecter vos politiques internes.En savoir plus
- Scan on-premisesScannez les applications de préproduction, API et dépôts derrière votre pare-feu ou VPN, sur une infrastructure que vous contrôlez.En savoir plus
Des banques et fintechs nous font confiance, dont
Sources
Les textes officiels sur lesquels s'appuie cette page, vérifiés le 27 septembre 2026.
- Supervisory Policy Manual TM-E-1 : Risk Management of E-banking (V.4)HKMA, 25 octobre 2024. Ligne directrice statutaire au titre de l'article 7(3) de la Banking Ordinance. Évaluation indépendante, tests d'intrusion annuels, 2FA, protection des clients, et banque en ligne accédée depuis un appareil mobile (7.1)
- Supervisory Policy Manual TM-G-1 : General Principles for Technology Risk Management (V.1)HKMA, 24 juin 2003. Note d'orientation non statutaire. Authentification et contrôle d'accès, sécurité des systèmes et gestion des correctifs, et développement et gestion des changements ; citée par le code sectoriel du PCICSO de 2026
- Supervisory Policy Manual TM-C-1 : Supervisory Approach on Cyber Risk Management (V.1)HKMA, 29 novembre 2024. Ligne directrice statutaire. Le cadre d'évaluation de la cyber-résilience et l'iCAST, la réponse aux incidents et le rétablissement, et la sauvegarde tertiaire sécurisée
- Supervisory Policy Manual OR-2 : Operational Resilience (V.1)HKMA, 31 mai 2022. Note d'orientation non statutaire. Opérations critiques, tolérance aux perturbations et tests de scénarios graves mais plausibles, y compris les défaillances chez un tiers ou dans sa chaîne d'approvisionnement
- Cybersecurity Fortification Initiative 2.0, circulaire et annexeHKMA, 3 novembre 2020, en vigueur le 1er janvier 2021. C-RAF 2.0, exigences de Blue Team pour l'iCAST et calendrier d'évaluation échelonné pour les trois groupes d'IA
- New Anti-Digital Fraud Measures: E-Banking Security ABC, circulaire et annexeHKMA, 14 avril 2025. Authentification par appareil lié par défaut au lieu des mots de passe à usage unique par SMS, reconnaissance faciale pour la liaison et la nouvelle liaison d'appareil, et calendrier de mise en œuvre du deuxième au quatrième trimestre 2025
- E-Banking Security ABCD, circulaire et annexe : Good Practices for Countering Deepfake AttacksHKMA, 25 août 2025, effet immédiat. Contrôles de sécurité des appareils, tests de vivacité randomisés, analyses d'images et surveillance des traces anormales pour la vérification d'identité
- Code de pratique pour les IA désignées opérateurs d'infrastructures critiques au titre du PCICSOMonetary Authority, 2 juin 2026, en vigueur le jour même. Publié au titre de l'article 8(1)(b) de la Protection of Critical Infrastructures (Computer Systems) Ordinance. Plan de gestion de la sécurité, évaluation annuelle des risques avec évaluation de vulnérabilité et test d'intrusion, et audit indépendant tous les 24 mois
Questions fréquentes
Des réponses claires sur la couverture, la mise en place et la façon dont les résultats parviennent à vos équipes.
Vous ne trouvez pas votre réponse ? Réservez une démo ou contactez-nous.
Évaluez votre application bancaire mobile comme le décrit la HKMA
Commencez par un scan gratuit de votre application depuis le store, ou réservez une démo pour lancer des tests authentifiés de votre application et de vos API avec notre équipe.