Règles de la RBI : évaluez votre application bancaire mobile avant et après chaque version.

1. 01

   Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, paragraphes 149 à 161

   Tester les applications critiques exposées à Internet à intervalles fixes

   Ce que dit le texte

   Réalisez périodiquement des exercices de VA et de PT pour tous les systèmes critiques et exposés à Internet, et réalisez périodiquement des VA et PT des applications web et mobiles critiques exposées à Internet tout au long de leur cycle de vie, y compris avant la mise en œuvre, après la mise en œuvre et après les changements. Pour les systèmes d'information critiques, et pour les systèmes en DMZ ayant une interface client, réalisez une VA au moins tous les six mois et un PT au moins une fois tous les 12 mois ; pour les autres systèmes, adoptez une approche fondée sur les risques. Les tests après mise en œuvre sont réalisés sur l'environnement de production, ou sur un environnement de test qui ressemble à la production, toute déviation étant documentée et approuvée. Corrigez les vulnérabilités identifiées dans des délais fixés et présentez le statut de clôture au comité de stratégie informatique et au comité de sécurité de l'information au moins chaque trimestre.

   Source :Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, paragraphes 149 à 161

   Ce que cela implique pour votre application mobile

   Votre application mobile est une application critique exposée à Internet avec une interface client. Elle a besoin d'une VA semestrielle, d'un PT annuel et de tests après chaque changement, pas seulement une fois au lancement.

   Comment Ostorlab vous aide

   Mobile SAST analyse le binaire, y compris les SDK intégrés, et Mobile DAST teste l'application en cours d'exécution ; les deux s'exécutent dans la CI/CD. Le pentest par agents IA teste l'application et ses API derrière la connexion, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA.

   Ce qui reste de votre ressort

   La définition du périmètre et de la fréquence pour les serveurs et les composants réseau, la nomination des auditeurs VA et PT, et le reporting de la clôture aux comités.

2. 02

   Reserve Bank of India (Commercial Banks – Digital Payment Security Controls) Directions, 2026, paragraphe 68 ; Master Direction on Digital Payment Security Controls, 18 février 2021, chapitre IV, pour la formulation antérieure

   Appliquer les contrôles des applications de paiement mobile

   Ce que dit le texte

   Les contrôles des applications de paiement mobile exigent que la banque puisse vérifier la version de l'application avant d'activer les transactions, et qu'elle mette en œuvre l'application de la politique d'appareil sur la base de son évaluation des risques, notamment des contrôles du système d'exploitation vulnérable, des applications vulnérables ou malveillantes et des configurations Wi-Fi non sécurisées ; le bac à sable ou la conteneurisation et le chiffrement de l'application ; la collecte minimale de données et de permissions ; l'identification des applications d'accès à distance et l'interdiction de la connexion depuis celles-ci ; et l'obfuscation du code. Les anciennes versions de l'application doivent être désactivées de manière progressive et dans des délais fixés, sans dépasser six mois après la publication d'une version plus récente. La banque doit héberger la somme de contrôle de la version active sur une plateforme publique, mettre en œuvre la liaison d'appareil, exiger une ré-authentification après une période d'inactivité et à chaque lancement, et identifier les connexions depuis des réseaux non sécurisés. La banque peut aussi valider la sécurité et la compatibilité de l'appareil, du système d'exploitation et de l'application, et peut vérifier si un appareil est rooté ou jailbreaké avant l'installation et empêcher l'application de s'installer ou de fonctionner dans ce cas.

   Source :Reserve Bank of India (Commercial Banks – Digital Payment Security Controls) Directions, 2026, paragraphe 68 ; Master Direction on Digital Payment Security Controls, 18 février 2021, chapitre IV, pour la formulation antérieure

   Ce que cela implique pour votre application mobile

   Ce sont des contrôles que votre application possède ou non, et chacun est testable sur le build que téléchargent vos clients : contrôles de root et de jailbreak, détection de l'accès à distance, obfuscation, contrôles de version et liaison d'appareil.

   Comment Ostorlab vous aide

   Mobile Shielding Scan teste à l'exécution la détection du root et du jailbreak, l'anti-altération et le pinning, et montre quelles protections ont tenu et lesquelles ont été contournées. Ostorlab indique aussi la version de l'application, les permissions et les connexions réseau qu'il observe.

   Ce qui reste de votre ressort

   La rédaction de la politique d'appareil, l'hébergement de la somme de contrôle, la tenue des registres de liaison d'appareil et la notification des clients lors de nouvelles inscriptions d'appareil.

3. 03

   Reserve Bank of India (Commercial Banks – Digital Payment Security Controls) Directions, 2026, paragraphes 27 à 39 ; Cybersecurity Directions, 2026, paragraphes 83 à 87

   Intégrer la sécurité dès la conception et tester avant et après la mise en production

   Ce que dit le texte

   Adoptez une approche de sécurité dès la conception et intégrez la sécurité à toutes les étapes du cycle de vie de l'application : objectifs de sécurité aux phases d'exigences, de conception, de développement, de test, de mise en œuvre et de décommissionnement ; modélisation des menaces ; pratiques de développement sécurisé ; et tests de sécurité alignés sur les normes mondiales, dont OWASP et OWASP MASVS. Réalisez des tests de sécurité, y compris la revue du code source, des VA et des PT, des applications de paiement numérique : VA au moins tous les six mois, PT au moins une fois par an, et les deux à chaque introduction d'une nouvelle application ou infrastructure ou en cas de changement majeur. Lorsque le code source n'appartient pas à la banque, obtenez du développeur de l'application un certificat attestant qu'elle est exempte de vulnérabilités connues, de logiciels malveillants et de canaux cachés. Comparez les résultats avec les scans précédents pour confirmer l'absence de récidive, et corrigez les vulnérabilités dans des délais fixés. Les orientations sur la cybersécurité ajoutent des tests de sécurité applicative des applications web et mobiles tout au long de leur cycle de vie, dans un environnement ressemblant à la production.

   Source :Reserve Bank of India (Commercial Banks – Digital Payment Security Controls) Directions, 2026, paragraphes 27 à 39 ; Cybersecurity Directions, 2026, paragraphes 83 à 87

   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.

   Ce qui reste de votre ressort

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

4. 04

   Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025, paragraphes 6, 8 et 9

   Deux facteurs, dont l'un dynamique

   Ce que dit le texte

   Toutes les transactions de paiement numérique doivent être authentifiées par au moins deux facteurs distincts, sauf exemption, et pour les transactions autres que les transactions par carte en présence, au moins un facteur doit être créé ou prouvé dynamiquement, c'est-à-dire que la preuve envoyée avec la transaction est unique à cette transaction. Le facteur doit être robuste : la compromission d'un facteur ne doit pas affecter la fiabilité de l'autre. Les émetteurs peuvent proposer un choix de facteurs, ajouter des contrôles fondés sur les risques selon le comportement et le contexte comme la localisation et les attributs de l'appareil, et doivent s'assurer de la robustesse et de l'intégrité du mécanisme avant son déploiement. Si une perte découle d'une transaction non conforme, l'émetteur doit indemniser intégralement le client sans réserve. La conformité était exigée au 1er avril 2026.

   Source :Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025, paragraphes 6, 8 et 9

   Ce que cela implique pour votre application mobile

   Le second facteur doit être imposé par le serveur à chaque paiement, et il doit être dynamique. Le SMS OTP est une option, mais les orientations en autorisent d'autres, comme la liaison d'appareil, la biométrie ou la PKI.

   Comment Ostorlab vous aide

   Les tests authentifiés saisissent les codes à usage unique reçus par SMS, e-mail ou TOTP avec vos comptes de test et testent l'application effective de la MFA, les parcours d'authentification renforcée et les appels d'API derrière les paiements.

   Ce qui reste de votre ressort

   Le choix des facteurs, l'analyse des exemptions, la communication aux clients et le processus d'indemnisation.

5. 05

   Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, paragraphes 107, 110 et 115 ; Digital Payment Security Controls Directions, 2026, paragraphe 46

   Authentifier les clients et les utilisateurs à privilèges

   Ce que dit le texte

   La banque doit mettre en œuvre un cadre d'authentification qui assure une vérification positive de l'identité des clients accédant à ses services sur tous les canaux, et agir comme fournisseur d'identité pour l'accès des clients aux systèmes partenaires au moyen de technologies d'authentification sécurisées. Sur la base d'une évaluation des risques, elle doit mettre en œuvre une authentification à deux facteurs ou multifacteur, y compris la MFA obligatoire pour les utilisateurs à privilèges des systèmes d'information critiques et pour les activités critiques, et protéger les identifiants des utilisateurs, comme les identifiants de connexion, les informations d'authentification et les jetons, contre les fuites et les attaques. Les orientations sur la sécurité des paiements numériques ajoutent la MFA et des alertes pour toutes les transactions de paiement, y compris les débits et les crédits, les nouveaux rattachements de comptes, les modifications des données de compte et les révisions des plafonds de virement.

   Source :Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, paragraphes 107, 110 et 115 ; Digital Payment Security Controls Directions, 2026, paragraphe 46

   Ce que cela implique pour votre application mobile

   La connexion, les retraits, les modifications de bénéficiaires et de plafonds sont autant de moments où le backend doit exiger le bon facteur. La gestion des jetons sur l'appareil fait partie du même contrôle.

   Comment Ostorlab vous aide

   Ostorlab détecte les clés d'API, jetons et identifiants dans le package de l'application et vérifie s'ils sont fonctionnels, et teste les API à la recherche de contrôles d'autorisation défaillants (BOLA, BFLA, IDOR) et d'usages abusifs des jetons et des sessions.

   Ce qui reste de votre ressort

   La vérification d'identité, la gestion des accès à privilèges, les revues d'accès et le choix des technologies d'authentification.

6. 06

   Reserve Bank of India (Commercial Banks – Digital Payment Security Controls) Directions, 2026, paragraphes 48 à 51

   Sessions, tentatives échouées et alertes

   Ce que dit le texte

   Une session authentifiée et son protocole de chiffrement doivent rester intacts tout au long de l'interaction ; en cas d'interférence ou si le client ferme l'application, la session doit être terminée et les transactions concernées résolues ou annulées, le client étant informé rapidement. La banque doit fixer le nombre maximal de tentatives de connexion ou d'authentification échouées au-delà duquel l'accès est bloqué, disposer d'une procédure de réactivation sécurisée et informer le client des tentatives échouées. Elle doit aussi mettre en œuvre des mesures contre les attaques de l'homme du milieu, du navigateur et de l'application, afin que les données en transit soient sécurisées et que les transactions ne soient authentifiées que par une source ou un processus authentique.

   Source :Reserve Bank of India (Commercial Banks – Digital Payment Security Controls) Directions, 2026, paragraphes 48 à 51

   Ce que cela implique pour votre application mobile

   La gestion des sessions est un comportement testable : délais d'expiration, renouvellement des jetons, invalidation à la déconnexion ou à la fermeture de l'application, verrouillage après des tentatives échouées, et les appels d'API derrière chacun d'eux.

   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 le verrouillage, ainsi que les appels d'API qui les sous-tendent, et fournissent les étapes de reproduction de chaque résultat.

   Ce qui reste de votre ressort

   Les canaux d'alerte, le processus de réactivation et les règles de surveillance de la fraude qui exploitent les alertes.

7. 07

   Reserve Bank of India (Commercial Banks – Digital Payment Security Controls) Directions, 2026, paragraphes 22, 24 et 68(10) à 68(13) ; Digital Lending Directions, 2025, paragraphes 12 et 13

   Protéger les données sur l'appareil et en transit

   Ce que dit le texte

   Les applications web ne doivent pas stocker d'informations sensibles dans des champs cachés HTML, des cookies ou d'autres stockages côté client. Les contrôles cryptographiques doivent utiliser des longueurs de clés, des algorithmes, des suites de chiffrement et des protocoles robustes, non obsolètes ni démontrés comme non sécurisés. L'application mobile ne doit pas stocker ni conserver sur l'appareil d'informations personnelles ou d'authentification sensibles telles que les identifiants, mots de passe, clés, hachages ou références codées en dur, et doit effacer de manière sécurisée les informations sensibles des clients de la mémoire lorsque le client quitte l'application. Elle doit limiter ce qui est écrit dans les fichiers temporaires et sécuriser ce qui l'est, éviter les requêtes SQL brutes et l'injection SQL, et refuser de charger du contenu web lorsque des erreurs de négociation SSL ou TLS sont détectées. Les informations sensibles écrites dans la base de données de l'application doivent être chiffrées. Pour les applications de prêt, les Digital Lending Directions interdisent l'accès aux ressources du téléphone telles que les fichiers et médias, les listes de contacts, les journaux d'appels et les fonctions de téléphonie, et exigent que les données de prêt numérique soient stockées sur des serveurs en Inde.

   Source :Reserve Bank of India (Commercial Banks – Digital Payment Security Controls) Directions, 2026, paragraphes 22, 24 et 68(10) à 68(13) ; Digital Lending Directions, 2025, paragraphes 12 et 13

   Ce que cela implique pour votre application mobile

   Les mots de passe, jetons et données personnelles ne devraient jamais être stockés en clair sur le téléphone, dans des fichiers temporaires, des journaux ou des captures d'écran, ni transiter sans protection vers le backend.

   Comment Ostorlab vous aide

   Ostorlab recherche les jetons de session et les données personnelles dans le stockage local, les caches, les journaux, les fichiers temporaires et les captures d'écran, détecte les erreurs de configuration qui affaiblissent la protection du transport et des sessions, et capture des preuves sur le système de fichiers montrant ce qui a été écrit, où et quand.

   Ce qui reste de votre ressort

   La classification des données, la gestion des clés, les sauvegardes, les notices de confidentialité et la prévention des fuites de données.

8. 08

   Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, paragraphes 47 et 126 à 135 ; Digital Payment Security Controls Directions, 2026, paragraphe 32

   Connaître ses composants et ses tiers

   Ce que dit le texte

   Tenez un inventaire à jour des actifs informationnels, y compris les applications métier, l'infrastructure informatique de support, le matériel, les logiciels et les services, en indiquant leur criticité pour l'activité. Les orientations sur la sécurité des paiements numériques exigent que la banque obtienne du développeur ou du fournisseur de l'application un certificat ou une confirmation écrite attestant que l'application est exempte de vulnérabilités connues, de logiciels malveillants et de canaux cachés, à chaque changement important du code, et qu'elle mette en place un séquestre du code source ou d'autres arrangements pour les applications sous licence de tiers. Les arrangements avec des tiers nécessitent une évaluation du risque fournisseur proportionnée au risque et à la matérialité, des vérifications préalables et une surveillance, des accords prévoyant des droits d'audit, et une attention à la localisation géographique de l'infrastructure et aux mouvements transfrontaliers de données.

   Source :Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, paragraphes 47 et 126 à 135 ; Digital Payment Security Controls Directions, 2026, paragraphe 32

   Ce que cela implique pour votre application mobile

   Une application bancaire mobile embarque des SDK tiers qui communiquent avec leurs propres backends. Ils ont leur place dans votre inventaire d'actifs, votre SBOM et votre vision du risque lié aux tiers.

   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, les rapproche des vulnérabilités connues version après version, et montre ce que l'application et ses SDK échangent avec les backends sur le réseau.

   Ce qui reste de votre ressort

   L'inventaire des actifs, les vérifications préalables sur les fournisseurs, les certificats, les arrangements de séquestre et les contrats.

9. 09

   Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, paragraphes 37, 98 à 103 et 153

   Gérer les vulnérabilités et les correctifs avec des délais

   Ce que dit le texte

   Mettez en place des politiques documentées de gestion des changements et des correctifs qui évaluent l'impact business des correctifs, les appliquent de manière sécurisée et en temps utile avec les approbations nécessaires, et prévoient un moyen de récupérer après un déploiement échoué. Adoptez une stratégie documentée et fondée sur les risques pour tenir un inventaire des composants à corriger, identifier les correctifs applicables et les appliquer à temps afin de minimiser le nombre de systèmes vulnérables et la durée d'exposition. Surveillez les dates de fin de support des logiciels et évitez les logiciels obsolètes ou non pris en charge. Corrigez les vulnérabilités identifiées dans des délais fixés et vérifiez que les vulnérabilités connues, comme celles de la base CVE, ne réapparaissent pas.

   Source :Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, paragraphes 37, 98 à 103 et 153

   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 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'application des correctifs sur les serveurs et l'infrastructure, les contrats de maintenance des fournisseurs et les décisions d'acceptation des risques.

10. 10

    Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, paragraphe 182 ; directives CERT-In No. 20(3)/2022-CERT-In, 28 avril 2022 ; Digital Personal Data Protection Rules, 2025, règles 6 et 7

    Signaler les incidents et les violations, conserver les journaux en Inde

    Ce que dit le texte

    Les incidents cyber doivent être signalés dans les six heures suivant leur détection sur la plateforme DAKSH, le système avancé de surveillance prudentielle de la RBI, et la banque doit aussi notifier le CERT-In. Selon les directives CERT-In de 2022, les incidents spécifiés doivent parvenir au CERT-In dans les six heures suivant leur détection, les journaux des systèmes TIC doivent être conservés de manière sécurisée pendant 180 jours glissants sur le territoire indien, et les horloges des systèmes doivent être synchronisées sur l'heure du NIC ou du NPL. Selon les DPDP Rules de 2025, une violation de données personnelles doit être notifiée sans délai aux personnes concernées et au Data Protection Board, avec des informations détaillées dans les 72 heures, et les journaux de sécurité doivent être conservés un an.

    Source :Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, paragraphe 182 ; directives CERT-In No. 20(3)/2022-CERT-In, 28 avril 2022 ; Digital Personal Data Protection Rules, 2025, règles 6 et 7

    Ce que cela implique pour votre application mobile

    Une violation découverte via l'application ou une API fait courir le délai. Les fenêtres de six heures et de 72 heures partent de la détection, et les preuves doivent être prêtes.

    Comment Ostorlab vous aide

    Ostorlab ne signale pas d'incidents à la RBI, au CERT-In ou au Data Protection Board. Il vous fournit les preuves techniques, exploits rejouables et journaux de requêtes et réponses, dont vos équipes incident et juridique ont besoin pour le signalement.

    Ce qui reste de votre ressort

    La détection et la surveillance, les déclarations à DAKSH et au CERT-In, la notification des violations et l'analyse juridique.

Synthèse de textes publics de la RBI, du MeitY et du CERT-In, vérifiés le 27 septembre 2026. Les orientations de juillet 2026 s'appliquent aux banques commerciales ; la RBI a publié des orientations similaires par type d'entité pour les autres entités réglementées, et les textes de 2021 et 2023 cités ici ont été abrogés pour les banques commerciales le 31 juillet 2026. Cette page ne constitue pas un avis juridique.