Le RMiT de Bank Negara Malaysia : testez votre application bancaire mobile comme BNM le décrit.

1. 01

   RMiT, annexe 4, Control Measures for Mobile Applications and Devices, paragraphes 1 et 2

   Sécuriser l'application mobile et l'appareil qui l'exécute

   Ce que dit le texte

   Une institution financière doit connaître les risques liés aux applications mobiles et les évaluer en continu. Les services numériques comportant des informations sensibles sur les appareils mobiles doivent être correctement sécurisés : concevoir l'application pour qu'elle fonctionne dans un environnement sûr et inviolable, non compromis, jailbreaké ou rooté ; interdire le stockage des informations clients utilisées pour l'authentification auprès du serveur applicatif, comme les codes PIN et les mots de passe, et centraliser l'authentification et la vérification des clés et des PIN sur l'hôte ; soumettre l'activation de l'application à une authentification robuste ; assurer un provisionnement et un déprovisionnement sûrs ; et recourir à des plateformes de distribution réputées.

   Source :RMiT, annexe 4, Control Measures for Mobile Applications and Devices, paragraphes 1 et 2

   Ce que cela implique pour votre application mobile

   La détection du root et du jailbreak, la résistance à l'altération et l'emplacement des identifiants sont des contrôles nommés, pas des options. Ils doivent tenir à l'exécution, sur la version que téléchargent vos clients.

   Comment Ostorlab vous aide

   Mobile Shielding Scan exécute l'application dans des environnements rootés et jailbreakés, tente de contourner la détection du root et du jailbreak, l'anti-altération et le pinning, et montre si l'application bloque le parcours, refuse de démarrer ou continue de fonctionner. Ostorlab recherche aussi les PIN, jetons et données personnelles dans le stockage local, les caches, les journaux et les captures d'écran.

   Ce qui reste de votre ressort

   Le choix du produit de protection, le processus de provisionnement sûr et la surveillance des stores pour les fausses applications.

2. 02

   RMiT, annexe 3, Control Measures for Digital Services, paragraphes 4, 5, 6, 7 et 9

   Utiliser une MFA plus sûre que les SMS non chiffrés, avec des codes générés sur l'appareil

   Ce que dit le texte

   Pour les transactions financières et les transactions non financières à haut risque, y compris l'enregistrement d'un bénéficiaire favori et tous les transferts ultérieurs vers celui-ci, une institution financière doit adopter l'authentification multifacteur, demander à l'utilisateur de vérifier les détails de la transaction et envoyer des notifications en temps utile. La MFA doit résister au phishing, à l'interception et à la manipulation, et les canaux utilisés doivent être plus sûrs que les SMS non chiffrés. Lorsqu'un OTP est utilisé, il doit être dynamique et limité dans le temps, lié aux détails de la transaction et généré depuis l'appareil du client, et non depuis le serveur de la banque. Les institutions doivent aussi proposer une authentification fondée sur une clé cryptographique, comme un certificat numérique ou le passwordless, en alternative aux mots de passe.

   Source :RMiT, annexe 3, Control Measures for Digital Services, paragraphes 4, 5, 6, 7 et 9

   Ce que cela implique pour votre application mobile

   Le second facteur doit être imposé par le serveur à chaque transaction financière, et le code doit porter le bénéficiaire et le montant qu'il approuve. Les SMS seuls ne suffisent plus.

   Comment Ostorlab vous aide

   Les tests authentifiés couvrent la connexion et la déconnexion, le renouvellement des jetons, les délais d'expiration, l'invalidation des sessions et l'application effective de la MFA, y compris les parcours d'authentification renforcée, ainsi que les appels d'API qui les sous-tendent. Ostorlab saisit les codes à usage unique reçus par SMS, e-mail ou TOTP avec vos comptes de test et teste le comportement des parcours lorsqu'une étape est sautée ou rejouée.

   Ce qui reste de votre ressort

   Le choix et le déploiement de la MFA et des méthodes par passkey ou certificat, et la gestion de la migration hors des SMS OTP pour votre clientèle.

3. 03

   RMiT, annexe 3, Control Measures for Digital Services, paragraphe 3

   Lier l'appareil et protéger la modification des coordonnées clients

   Ce que dit le texte

   L'enregistrement et la mise à jour des appareils mobiles et des coordonnées clients utilisées pour l'authentification, comme le numéro de téléphone mobile, l'e-mail et l'adresse postale, doivent être renforcés pour empêcher les fraudeurs d'utiliser des identifiants volés pour déplacer des fonds. Les contrôles comprennent la liaison et la déliaison sûres d'un appareil mobile ou sécurisé par titulaire de compte par défaut ; des alertes immédiates en cas d'accès au compte depuis un nouvel appareil ou de modification des coordonnées ; une vérification robuste avant l'enregistrement d'un nouveau numéro ou du remplacement du numéro existant ; une période de réflexion pour la première souscription et les schémas de transactions anormaux ; et une vérification pour l'augmentation des limites de transaction.

   Source :RMiT, annexe 3, Control Measures for Digital Services, paragraphe 3

   Ce que cela implique pour votre application mobile

   La modification du numéro de téléphone et de l'e-mail est l'étape dont les fraudeurs ont besoin avant de prendre le contrôle d'un compte. La modification, l'alerte et la période de réflexion doivent être imposées par le backend, pas seulement affichées dans l'application.

   Comment Ostorlab vous aide

   Ostorlab teste les appels d'API derrière l'enregistrement d'un appareil, la modification des coordonnées, l'enregistrement d'un bénéficiaire et la modification des limites, y compris si un second facteur est exigé et si les règles de réflexion ou de limite peuvent être contournées via l'API.

   Ce qui reste de votre ressort

   Les procédures de vérification et de réflexion elles-mêmes, et les canaux d'alerte.

4. 04

   RMiT, annexe 5, Control Measures on Cybersecurity, partie E : Application Programming Interface (API) Security, paragraphe 1

   Évaluer et durcir vos API

   Ce que dit le texte

   La sécurité des API doit être proportionnée aux risques. Au minimum : tenir un inventaire centralisé des API couvrant toutes les connexions et dépendances ; concevoir les API pour absorber un trafic élevé et atténuer les dénis de service ; appliquer des pratiques de développement sécurisé, notamment la validation du code et des bibliothèques tiers, une gestion robuste des erreurs, la validation des entrées et les en-têtes de sécurité ; utiliser un chiffrement robuste et une bonne gestion des clés ; déployer des mécanismes anti force brute comme la limitation de débit et le verrouillage de compte ; mettre en œuvre une authentification et une autorisation fortes ; envisager une passerelle API ; réaliser des évaluations de sécurité périodiques des API, y compris des tests d'intrusion et des tests de sécurité statiques ou dynamiques ; surveiller l'usage des API ; et prévoir un processus de révocation des jetons d'accès ou des clés d'API après une compromission.

   Source :RMiT, annexe 5, Control Measures on Cybersecurity, partie E : Application Programming Interface (API) Security, paragraphe 1

   Ce que cela implique pour votre application mobile

   Toutes les API appelées par l'application sont concernées, y compris celles derrière la connexion. La limitation de débit, le verrouillage et la révocation des jetons sont des comportements testables, pas seulement des documents de conception.

   Comment Ostorlab vous aide

   Ostorlab intercepte le trafic de l'application, même avec TLS pinning, et teste les API à la recherche de contrôles d'autorisation défaillants (BOLA, BFLA, IDOR), d'usages abusifs des jetons et des sessions, et d'abus comme l'énumération, le rejeu et l'automatisation, avec les requêtes et réponses à l'appui pour chaque résultat.

   Ce qui reste de votre ressort

   L'inventaire des API, la passerelle, la surveillance des API et le processus de révocation.

5. 05

   RMiT, annexe 5, partie D : Vulnerability Assessment and Penetration Test (VAPT), paragraphes 1 à 6 ; RMiT paragraphe 11.6

   Respecter le rythme VAPT fixé par BNM

   Ce que dit le texte

   Une institution financière doit disposer de procédures opérationnelles standard pour l'évaluation des vulnérabilités et les tests d'intrusion, avec la supervision des testeurs externes, la validation des journaux d'événements et la purge des données. Elle doit réaliser une évaluation trimestrielle des vulnérabilités des composants réseau externes et internes qui soutiennent tous les systèmes critiques, et des tests d'intrusion annuels fondés sur le renseignement sur son infrastructure réseau interne et externe, ses systèmes critiques et ses services numériques, y compris le web, le mobile et toutes les applications exposées à l'extérieur, avec des scénarios d'attaque extrêmes mais plausibles et des testeurs dûment accrédités. Les nouveaux systèmes destinés à de nouveaux produits ou services doivent aussi être testés avant leur mise en service. Les résultats sont documentés et escaladés à la direction générale. Une évaluation indépendante des compromissions est exigée au moins tous les trois ans, et une simulation de red team au moins tous les trois ans.

   Source :RMiT, annexe 5, partie D : Vulnerability Assessment and Penetration Test (VAPT), paragraphes 1 à 6 ; RMiT paragraphe 11.6

   Ce que cela implique pour votre application mobile

   L'application et ses API entrent dans le périmètre du test annuel fondé sur le renseignement, et les nouveaux services numériques sont testés avant leur lancement. Entre ces tests, chaque version reste une modification d'un canal exposé à Internet.

   Comment Ostorlab vous aide

   Un pentest par agents IA teste l'application et ses API derrière la connexion, sur la version que vous livrez, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA. Les résultats sont suivis sous forme de tickets et retestés après publication du correctif, afin que les points relatifs à l'application et aux API de votre plan de remédiation soient clos avant le test annuel.

   Ce qui reste de votre ressort

   Le cadrage et la réalisation des évaluations trimestrielles, le test d'intrusion annuel fondé sur le renseignement avec des testeurs accrédités, l'évaluation des compromissions et l'exercice de red team.

6. 06

   RMiT, paragraphes 10.5, 10.6, 10.8, 10.9, 10.10 et 10.12

   Intégrer la sécurité dans le SDLC et tester avant la mise en production

   Ce que dit le texte

   Le cycle de vie du développement des systèmes doit couvrir les exigences, la conception, le développement, les tests, le déploiement, la gestion des changements, la maintenance et la mise hors service, et intégrer les principes et exigences de sécurité. Les méthodes de développement rapide comme DevOps doivent automatiser la revue de conformité de sécurité informatique ainsi que la découverte et le test des vulnérabilités. Les tests système avant déploiement doivent être rigoureux, et leur périmètre peut inclure les tests de sécurité applicative. Les modifications du code source des systèmes critiques doivent faire l'objet de revues de code adéquates. Lorsqu'un tiers développe ou maintient un système critique, les contrats doivent exiger des principes de sécurité dès la conception et un accès continu au code source.

   Source :RMiT, paragraphes 10.5, 10.6, 10.8, 10.9, 10.10 et 10.12

   Ce que cela implique pour votre application mobile

   Chaque version de l'application modifie un canal exposé à Internet. Les tests automatisés dans le pipeline couvrent l'avant ; les scans des versions publiées sur les stores couvrent l'après.

   Comment Ostorlab vous aide

   Ostorlab lance des scans automatisés depuis votre pipeline CI/CD à chaque build et surveille les versions publiées sur les stores sans déclenchement manuel. Mobile SAST fonctionne sur l'APK, l'AAB ou l'IPA, sans besoin du code source, et Mobile DAST exerce l'application en cours d'exécution.

   Ce qui reste de votre ressort

   Les exigences de sécurité, les normes de développement sécurisé, les revues manuelles de code et l'approbation des mises en production.

7. 07

   RMiT, paragraphes 10.15, 10.17 et 10.18

   Gérer les composants, les correctifs et les systèmes en fin de vie

   Ce que dit le texte

   Les systèmes, y compris les services numériques, ne doivent pas fonctionner avec des vulnérabilités connues, sur des plateformes obsolètes ou des technologies en fin de vie. Les institutions doivent maintenir une base de sécurité à jour, surveiller et appliquer en temps utile les derniers correctifs, planifier les mesures correctives pour les systèmes proches de la fin de vie et obtenir l'approbation de la direction pour les exceptions. Le cadre de gestion des correctifs et de la fin de vie doit fixer des critères, des priorités et des délais selon la gravité des vulnérabilités identifiées. Pour les logiciels tiers, BNM encourage une nomenclature logicielle (SBOM) et une politique de sécurité des logiciels open source, incluant des tests robustes des logiciels open source et une évaluation rapide des vulnérabilités.

   Source :RMiT, paragraphes 10.15, 10.17 et 10.18

   Ce que cela implique pour votre application mobile

   Les bibliothèques et SDK de votre application sont des logiciels que vous livrez. Chacun doit avoir une version connue, une gravité lorsqu'une vulnérabilité apparaît, et un délai de correction dont vous pouvez apporter la preuve.

   Comment Ostorlab vous aide

   SCA identifie les bibliothèques compilées statiquement et les associe aux vulnérabilités connues, d'une version à l'autre. Mobile SAST et SCA recensent les SDK et bibliothèques natives de chaque version avec leurs versions, et les résultats sont classés critiques, élevés, moyens ou faibles et suivis sous forme de tickets.

   Ce qui reste de votre ressort

   L'application des correctifs sur les serveurs et l'infrastructure, les contrats de maintenance des fournisseurs et les décisions d'acceptation des risques.

8. 08

   Management of Customer Information and Permitted Disclosures, paragraphes 10.12, 10.26, 10.31, 11.8, 11.19, 11.20 et 11.25 ; Personal Data Protection (Amendment) Act 2024, section 12B

   Protéger les informations clients et gérer les violations

   Ce que dit le texte

   Le document de politique Management of Customer Information and Permitted Disclosures exige des contrôles informatiques préventifs et détectifs contre le vol, la perte, l'usage abusif ou l'accès, la modification ou la divulgation non autorisés des informations clients, des contrôles d'accès au niveau applicatif, base de données, système d'exploitation et réseau, des contrôles pour les informations collectées hors site et en transit, et une destruction sûre. Une violation des informations clients qui présente un risque de réputation, cause ou est susceptible de causer un préjudice important, ou concerne un grand nombre de clients, doit être signalée immédiatement à BNM, faire l'objet d'une enquête dans les trois mois, et être signalée à BNM dans le jour ouvrable suivant sa présentation au conseil. Les clients concernés doivent être notifiés sans retard injustifié. Les amendements à la PDPA ajoutent la même obligation envers le Commissaire à la protection des données personnelles, la notification des violations et la nomination d'un délégué prenant effet le 1er juin 2025.

   Source :Management of Customer Information and Permitted Disclosures, paragraphes 10.12, 10.26, 10.31, 11.8, 11.19, 11.20 et 11.25 ; Personal Data Protection (Amendment) Act 2024, section 12B

   Ce que cela implique pour votre application mobile

   Les données personnelles écrites sur le téléphone, dans ses caches, ses journaux ou ses captures d'écran font partie de votre surface de violation, et les API qui les transportent sont l'endroit où le contrôle d'accès doit tenir.

   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, et détecte les erreurs de configuration qui affaiblissent la protection du transport et des sessions. Chaque résultat est accompagné de preuves sur le système de fichiers ou de requêtes et réponses à conserver.

   Ce qui reste de votre ressort

   La classification des données, la gestion des clés, l'enquête sur les violations et la notification à BNM, au Commissaire et aux clients.

9. 09

   RMiT, paragraphes 10.47, 10.48 et 10.49 ; Personal Data Protection (Amendment) Act 2024, section 5

   Gérer les tiers et ce qu'ils intègrent à votre application

   Ce que dit le texte

   Avant d'intégrer un tiers, et tout au long de la relation, une institution financière doit mener une diligence raisonnable et maintenir un accord de niveau de service couvrant les droits d'accès, la confidentialité, la notification des incidents, la continuité d'activité et la sortie. Elle doit élaborer une feuille de route pour surveiller en continu la posture de cybersécurité du tiers, mesurer l'empreinte de l'infrastructure informatique et les informations clients accessibles aux tiers, et intégrer les protocoles tiers dans la réponse aux incidents. Selon les amendements à la PDPA, le principe de sécurité s'applique désormais aussi aux sous-traitants de données, et pas seulement aux responsables du traitement.

   Source :RMiT, paragraphes 10.47, 10.48 et 10.49 ; Personal Data Protection (Amendment) Act 2024, section 5

   Ce que cela implique pour votre application mobile

   Une application bancaire mobile embarque des SDK tiers qui communiquent avec leurs propres backends et peuvent traiter des données personnelles. Ils ont leur place dans votre inventaire, votre vision du risque tiers et vos accords de sous-traitance.

   Comment Ostorlab vous aide

   Ostorlab recense les SDK et bibliothèques natives de chaque version avec leurs versions et leur emplacement dans le bundle de l'application, et montre ce que l'application et ses SDK échangent avec les backends sur le réseau. Il n'assure pas la surveillance continue des tiers.

   Ce qui reste de votre ressort

   La diligence raisonnable, les contrats, la feuille de route de surveillance et les accords de sous-traitance.

10. 10

    RMiT, annexe 12, Code of Practice for NCII Entities, paragraphes 11.3.2 à 11.3.6

    Si vous êtes désigné entité NCII, respectez le code de pratique

    Ce que dit le texte

    Les banques désignées par BNM comme entités d'infrastructure d'information critique nationale au titre du Cyber Security Act 2024 doivent se conformer à l'annexe 12 du RMiT, qui constitue leur code de pratique. Elle exige des lignes directrices de cybersécurité pour le développement de logiciels et de systèmes couvrant les pratiques de développement sécurisé alignées sur l'OWASP Top 10, les mécanismes de contrôle d'accès dans les applications et les exigences de mises à jour et de correctifs réguliers, appliquées tout au long du SDLC et des acquisitions tierces. Des tests de sécurité doivent être menés pendant le développement, suivis de tests d'intrusion avant le déploiement en production ou dans un environnement public, notamment des scans de vulnérabilités, des tests d'intrusion et la validation du respect des règles de développement sécurisé.

    Source :RMiT, annexe 12, Code of Practice for NCII Entities, paragraphes 11.3.2 à 11.3.6

    Ce que cela implique pour votre application mobile

    Pour les banques désignées, cela ajoute un parcours documenté et testable de développement sécurisé et de tests avant déploiement pour le canal mobile.

    Comment Ostorlab vous aide

    Ostorlab couvre ces vérifications avant déploiement : Mobile SAST sur le build, Mobile DAST sur l'application en cours d'exécution, SCA sur les composants, et un pentest par agents IA de l'application et de ses API avec un exploit rejouable pour chaque résultat.

    Ce qui reste de votre ressort

    Les lignes directrices de développement sécurisé, les approbations du comité de gouvernance et la décision de déploiement en production.

Synthèse des textes publics de BNM, vérifiés le 27 septembre 2026. Le texte du RMiT cité est la révision en vigueur, publiée le 28 novembre 2025 et rééditée le 25 septembre 2026. Cette page ne constitue pas un avis juridique.