CBO Cyber Security & Resilience Framework: assess your mobile banking app before and after every release.

1. 01

   Cyber Security & Resilience Framework (CS&RF), 3.3.11, controlling measures 1 to 5

   Run vulnerability assessments and penetration tests on critical systems

   What the text says

   Each licensed institution should periodically conduct vulnerability assessment to identify security vulnerabilities in its information assets, with frequency based on the criticality of the assets. Penetration testing should also be carried out, with frequency based on the criticality of the systems and the institution's exposure to cyber risk. For internet-facing systems, penetration testing should be conducted at least annually or whenever there are significant changes to the systems or an update. Institutions should establish processes for remediating the vulnerabilities found and validate the remediation to make sure the gaps are fully addressed, and should report identified vulnerabilities to the IT and Risk Management committee. Regular cyber simulation exercises should also be conducted.

   Source:Cyber Security & Resilience Framework (CS&RF), 3.3.11, controlling measures 1 to 5

   What it means for your mobile app

   The mobile banking app and the APIs behind it are internet-facing systems. The framework expects a set cadence, a validated fix process and committee reporting, not a one-off test.

   How Ostorlab helps

   Ostorlab runs AI-agent penetration tests of the app and its APIs behind login on the build you ship, plus Mobile SAST and DAST in CI/CD. Each AI-agent finding comes with a working exploit you can replay, and retests confirm the fix.

   What stays with you

   Setting the frequency, testing servers, VPN equipment and other platforms, running simulation exercises, and reporting to the IT and Risk Management committee.

2. 02

   Regulatory Framework for Digital Banks, Decision 25/2025, 6.1(o), 6.1(s), 11.1 and 11.3

   Meet the digital banking framework's security expectations

   What the text says

   Applicants and licensed digital banks must demonstrate compliance with the Banking Law and the National Payment Systems Law, the Cyber Security & Resilience Framework, the Instructions on Digital Onboarding and Electronic KYC, the anti-money laundering framework, the anti-fraud framework, and the rules for outsourcing and cloud services. Their business plans must show ex-ante technological preparedness such as zero-trust architecture, industry-grade certifications like PCI-DSS, and measures to identify, protect, detect, respond and recover from cyber threats. The Central Bank may require the applicant to appoint a qualified third-party assessor to perform vulnerability assessment and penetration testing at the applicant's expense, at different stages of its operations.

   Source:Regulatory Framework for Digital Banks, Decision 25/2025, 6.1(o), 6.1(s), 11.1 and 11.3

   What it means for your mobile app

   If you are building or running a digital bank, the app and API layer is where the framework's cyber security, e-KYC and anti-fraud requirements meet.

   How Ostorlab helps

   Ostorlab provides the technical testing on the app and API side: AI-agent pentests, authenticated testing and API testing, with evidence for each result. It is not the licensing assessor and does not certify PCI-DSS.

   What stays with you

   The licence application and business plan, the choice of assessor, and the wider programmes for zero trust, fraud and cloud governance.

3. 03

   CS&RF, 3.3.2, controlling measures 1 to 4

   Secure the application layer and what you build with

   What the text says

   Application configurations should comply with the applicable information security policies and procedures, and audit trails for critical applications must be maintained and reviewed in case of an incident. A risk analysis must be documented for each application requiring network access. Institutions should have policies and procedures on the use of third-party and open-source code, and should perform source code reviews and testing for in-house and custom-developed applications to find vulnerabilities arising from coding issues, poor coding practices or malicious attempts.

   Source:CS&RF, 3.3.2, controlling measures 1 to 4

   What it means for your mobile app

   A mobile banking app is custom code plus third-party SDKs. The framework expects both to be governed and tested, not just the backend.

   How Ostorlab helps

   Mobile SAST works on the APK, AAB or IPA without source code, with taint analysis across the app and its embedded SDKs. SCA and SBOM list the third-party and native components in each release and map them to known vulnerabilities.

   What stays with you

   Secure coding standards, manual code reviews, configuration baselines, and the policy on open-source use.

4. 04

   CS&RF, 3.5.2, controlling measures 1 and 2; BM 1153, Annexure, 6(xxi) and 6(xxii)

   Enforce MFA and session controls for electronic banking

   What the text says

   Institutions should design multi-factor authentication methods that are comparatively strong and reliable, and should consider implementing MFA for registration, sign-on, password resets, adding or changing beneficiaries, high level transactions that exceed predefined limits, and adding government and utility payment services. Online sessions should be terminated automatically after a fixed period of time unless re-authenticated, and confirmatory second channel procedures such as SMS or email should be used for transactions above pre-set values, registration of third-party payee details, changing account details and revising funds transfer limits.

   Source:CS&RF, 3.5.2, controlling measures 1 and 2; BM 1153, Annexure, 6(xxi) and 6(xxii)

   What it means for your mobile app

   MFA has to be enforced by the server on every one of those operations, including when the app skips a step, and session expiry and second-channel confirmation are behaviours you can test.

   How Ostorlab helps

   Authenticated testing covers login and logout, one-time codes, step-up flows, token refresh, timeouts and session invalidation, together with the API calls behind registrations and beneficiary changes.

   What stays with you

   Choosing and deploying the MFA methods and the second channel, and customer communication.

5. 05

   CS&RF, 3.5.2, controlling measures 8 and 12; BM 1153, Annexure, 6(xxv) and 6(xxxi)(f)

   Keep mobile banking on official channels, with two-factor debits

   What the text says

   Institutions should make online and mobile banking available only through official applications stores or any other secure delivery channels, and should establish brand protection for their online services, including social media, and implement a detection measure to take down any malicious websites and apps. Mobile banking services should ensure appropriate risk mitigation measures such as transaction limits, transaction velocity limits and fraud and AML checks. All mobile banking transactions involving a debit to the account should be permitted only through two-factor authentication, and proper security should be ensured at all stages of processing mobile banking transactions. Where third parties are associated with electronic banking activities, institutions should bind them with liability clauses on security threats emanating from their systems.

   Source:CS&RF, 3.5.2, controlling measures 8 and 12; BM 1153, Annexure, 6(xxv) and 6(xxxi)(f)

   What it means for your mobile app

   The store build is your customer-facing channel. Clones and tampered builds, debit flows that skip the second factor, and limits that live only in the interface are all things the framework expects you to control.

   How Ostorlab helps

   Ostorlab scans the store build release after release and tests root and jailbreak detection, anti-tampering and TLS pinning at runtime, so you can see which protections held and which were bypassed. It also tests whether the two-factor checks and transaction limits hold on the server side.

   What stays with you

   Store monitoring and the takedown process for clones, the transaction and velocity limits themselves, and vendor liability clauses.

6. 06

   CS&RF, 3.3.8, patch management measures; BM 1153, Annexure, 6(xx)

   Patch on time and keep track of components

   What the text says

   Institutions should keep operating systems, network and infrastructure devices, security software and remote access computers updated and patched in accordance with a patch management policy, after due risk assessment. They should continuously monitor vendor patch releases and make sure critical patches are tested in a test environment before production; if a patch breaks a critical application, they should devise other mitigating controls that block exploitation. Where applications are bought from vendors, institutions should obtain application integrity statements in writing that the application is free of malware, bugs and covert channels, and there should be a risk management analysis and security vulnerability assessment of the application and network at least once a year.

   Source:CS&RF, 3.3.8, patch management measures; BM 1153, Annexure, 6(xx)

   What it means for your mobile app

   Every library, SDK and native component inside the app is software you ship. Each needs a known version, a severity when something breaks, and a fix deadline you can evidence.

   How Ostorlab helps

   SCA fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Findings are rated critical, high, medium or low, tracked as tickets in the platform or in Jira and ServiceNow, and retested once the fix ships.

   What stays with you

   Patching servers and infrastructure, vendor maintenance contracts, compensating controls, and risk acceptance decisions.

7. 07

   CS&RF, 3.3.5 and 3.5.1(7); Personal Data Protection Law (Royal Decree 6/2022), Articles 13, 14, 15 and 19, as amended by Royal Decree 68/2026

   Protect personal data on the device and in transit

   What the text says

   Institutions should implement endpoint, peripheral and network data loss prevention solutions, and should implement end to end encryption at rest and in transit for the protection of sensitive information such as login credentials and card information. Under the Personal Data Protection Law, the controller and the processor must put in place the controls and procedures for processing, including the risks the data subject is exposed to and the technical measures that guarantee the law is applied; when using automated processing they must protect privacy and confidentiality; they must erase personal data when the purpose of processing ends; and they must notify the ministry and the data subject of a personal data breach. Transfers of personal data outside Oman follow the controls in the executive regulation.

   Source:CS&RF, 3.3.5 and 3.5.1(7); Personal Data Protection Law (Royal Decree 6/2022), Articles 13, 14, 15 and 19, as amended by Royal Decree 68/2026

   What it means for your mobile app

   Passwords, tokens and card data should never sit in clear text on the phone or travel unprotected to the backend, and personal data collected by the app is subject to the data protection law.

   How Ostorlab helps

   Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, and checks for misconfigurations that weaken transport and session protections.

   What stays with you

   Data classification, consent notices, data protection officer duties, breach notification to the ministry and to data subjects, and transfer assessments.

8. 08

   CS&RF, 3.3.10, controlling measures 1 to 4

   Lock down access and credentials

   What the text says

   Institutions should define, approve and monitor a policy on access management, applying segregation of duties, need-to-have and least privilege when granting access to staff, contractors and third-party vendors. Records of user access activities should be uniquely logged and identified for audit and investigation purposes, and additional authentication mechanisms such as multi-factor authentication should be used for remote access and for privileged access to systems that support essential functions, based on a risk assessment.

   Source:CS&RF, 3.3.10, controlling measures 1 to 4

   What it means for your mobile app

   API keys, tokens and other credentials left in the app package are access that anyone who downloads the app can extract; authorisation between the app, the backend and external services has to hold at every boundary.

   How Ostorlab helps

   Ostorlab finds API keys, tokens and credentials in the app package and validates whether they work, and tests the APIs for broken authorization (BOLA, BFLA, IDOR) and misuse of tokens and sessions.

   What stays with you

   Privileged account management, access reviews, joiner and leaver processes, and third-party access control.

9. 09

   CS&RF, 3.5.2, controlling measure 14 (a) to (e)

   Test e-KYC and onboarding security

   What the text says

   For e-KYC, which lets institutions digitally onboard new customers and update know your customer records through electronic means, institutions should conduct cyber security assessments prior to launch of the e-KYC solution and assess periodically how effective the technology is in mitigating cyber threat risks and fraud risks. The identification and verification process should adopt an appropriate combination of multi-factor authentication, the application must make use of real time secured end-to-end encryption, and the digital footprint and logs collected during identification and verification should be preserved, including complementary data such as IP addresses. Video recordings should be stored safely with the date and time stamps maintained.

   Source:CS&RF, 3.5.2, controlling measure 14 (a) to (e)

   What it means for your mobile app

   Onboarding runs through the mobile app before an account exists. The encryption, the MFA combination and the evidence trail are all part of the app and API flow you can test.

   How Ostorlab helps

   Ostorlab completes onboarding and e-KYC flows with your test accounts and identity documents and tests the API calls behind them, including MFA enforcement, session handling and transport protections.

   What stays with you

   The identity verification product, liveness and document checks, video storage, and the retention policy for onboarding data.

Summary of public CBO texts and the Personal Data Protection Law, checked on 27 September 2026. The Cyber Security & Resilience Framework is enclosed with Circular BM 1194, and clause summaries follow the framework text. This page is not legal advice.