Central Bank of Kuwait CORF: test the mobile banking app your customers use.
The Central Bank of Kuwait released its Cyber and Operational Resilience Framework (CORF) on 3 December 2025, building on the 2020 Cybersecurity Framework. Its payments security baselines set concrete rules for mobile banking apps: block rooted and jailbroken devices, time out sessions after five minutes, keep one-time passwords valid for two minutes at most, and test apps and APIs with vulnerability assessments and penetration tests. Ostorlab supports your testing obligations for the app and the APIs behind it, on every release.
- Checks whether root and jailbreak detection holds, and what the app does when it triggers
- Tests login, one-time codes, step-up checks and session timeouts with your test accounts
- Follows the app into its APIs, even with TLS pinning, to test authorization and abuse
- Tracks findings to closure and retests each fix, with evidence you can keep
- Who it applies to
- All Regulated Entities under the supervision of the Central Bank of Kuwait
- Released
- CORF Version 1.0, 3 December 2025
- Focus
- Cyber and operational resilience, including online and mobile banking security
- Reference
- CORF Chapter 4, Cyber Resilience Baselines, domains 5 and 8
The CBK texts behind the mobile channel
The CORF is the latest step in a series of CBK texts on cybersecurity and electronic payments. The dates below are for the texts cited on this page.
- 23 December 2018
Electronic payment instructions
Circular No. (2/BS, BS, IBS/415/2018) issues the Instructions for Regulation of the Electronic Payment of Funds to local banks and other institutions.
- January 2020
Cybersecurity Framework
Version 1.0 of the Cybersecurity Framework for the Kuwaiti banking sector sets the first sector-wide cybersecurity baseline.
- 18 September 2023
Measures against electronic fraud
Circular No. (2/BS, IBS/534/2023) sets rules for adding beneficiaries, new devices and remote-control apps in internet and mobile banking.
- 3 December 2025
CORF Version 1.0
The Cyber and Operational Resilience Framework is released, moving from the 2020 framework to a resilience-first, maturity-oriented model.
- Every year
Risk profile, self-assessment and CBK review
Entities update the inherent risk profile and submit a self-assessment annually. CBK assesses Tier 1 entities every year, Tier 2 every eighteen months and Tier 3 every two years.
- Every quarter
Vulnerability reporting to the Board
The information security function updates the Board and senior management on the effectiveness of vulnerability management, quarterly or more often.
The CORF baselines, applied to your mobile app
The CORF's technology and payments security baselines, plus the CBK's circular on electronic fraud. For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team.
- CBK CORF, Chapter 4, 5.8.2.2 and 8.3.1.14
Test your apps with vulnerability assessments and penetration tests
What the text says
All applications, regardless of their type, must undergo comprehensive security assessments, including vulnerability assessments and penetration testing, on a periodic basis. Entities must also run periodic security assessments to identify and remediate vulnerabilities in their online banking platforms and mobile banking applications.
What it means for your mobile app
The mobile banking app is named explicitly. It needs regular vulnerability assessments and penetration tests, and the gaps they find need to be fixed.
How Ostorlab helps
Mobile SAST analyses the binary, including embedded SDKs, and Mobile DAST tests the running app; both run in CI/CD. The AI-agent pentest goes deeper behind login, with a working exploit you can replay for each AI-agent finding.
What stays with you
Setting the testing interval, scoping manual tests and approving remediation.
- CBK CORF, Chapter 4, 8.3.1.7, 8.1.3.3 and 8.3.3.3
Block rooted and jailbroken devices
What the text says
Entities must implement controls to prevent installation and block usage of mobile banking applications on jailbroken or rooted devices. Devices used for digital banking must be continuously verified against security policies, including OS version, patch levels and device integrity, and devices that fail must have their access restricted or revoked. Digital wallets must also block usage on jailbroken or rooted devices.
What it means for your mobile app
Root and jailbreak detection is a requirement, not an option. It has to trigger and the app has to react, even when an attacker tries to hide the device state.
How Ostorlab helps
Mobile Shielding Scan runs the app in rooted and jailbroken environments, attempts bypasses of root and jailbreak detection, anti-tampering, anti-instrumentation and TLS pinning, and shows whether the app blocks the workflow, refuses to start or keeps running. You get a hardening score and bypass evidence.
What stays with you
Choosing and configuring your shielding or runtime protection product, and the device compliance policy.
- CBK CORF, Chapter 4, 8.3.1.3 and 8.1.3.5
Use strong MFA for critical actions
What the text says
Entities must implement strong multi-factor authentication and out-of-band verification to authorize critical actions such as account activation, fund transfers, bill payments and beneficiary addition, using OTPs from third-party authenticator apps, in-app push notifications with biometric or PIN approval, or device-based authorization such as FIDO2. Changes to sensitive customer information, such as mobile number and email address, require MFA.
What it means for your mobile app
Every critical action in the app needs its own strong check, and that check has to hold on the server, whatever the app sends.
How Ostorlab helps
Ostorlab completes SMS, email or TOTP one-time codes with your test accounts and tests MFA enforcement and step-up flows, including how attackers try to manipulate them, together with the API calls behind account changes.
What stays with you
Choosing authentication methods and collecting customer consent for the OTP delivery method.
- CBK CORF, Chapter 4, 8.3.1.1, 8.3.1.2 and 8.1.3.1
Limit sessions, one-time passwords and failed logins
What the text says
Mobile banking sessions must end automatically after a maximum of five minutes of inactivity, and concurrent sessions are disallowed. One-time passwords are valid for a maximum of two minutes, and sessions must be revalidated at set intervals or when the session context changes. Access must be blocked after a maximum of three failed log-in or authentication attempts.
What it means for your mobile app
These are concrete, testable settings: the inactivity timeout, the ban on parallel sessions, OTP lifetime and the lockout threshold.
How Ostorlab helps
Authenticated testing covers login and logout, token refresh, timeouts, session invalidation and MFA enforcement, and traffic analysis shows how credentials travel from the app to the backend.
What stays with you
The reactivation procedure for blocked users and the revalidation triggers you choose.
- CBK CORF, Chapter 4, 8.3.1.8 to 8.3.1.10
Encrypt local data and bind the app to devices
What the text says
The mobile banking application must encrypt all data it stores locally on the customer's device. It must verify the customer's mobile number and use device authentication, such as device fingerprinting or certificate-based authentication, for first-time use. Customers may use the app from up to three validated devices, or up to six with strong risk mitigation controls.
What it means for your mobile app
What the app writes to the device, and how it recognises a new device, are both in scope.
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. Authenticated testing covers the login and device flows behind your test accounts.
What stays with you
Device registration limits, revalidation of registered devices and customer notifications.
- CBK CORF, Chapter 4, 5.8.3.1 to 5.8.3.8 and 8.3.2.7
Secure your APIs and assess them after major changes
What the text says
APIs must follow secure coding practices such as the OWASP API Security Top 10, enforce strong authentication and role-based access control, validate all inputs, apply rate limiting and throttling, and encrypt traffic. APIs must undergo security assessments on a periodic basis and after major changes, such as penetration testing, fuzzing, DAST/SAST, runtime testing and misconfiguration testing. Open banking APIs must be assessed periodically with penetration tests and vulnerability assessments.
What it means for your mobile app
The APIs behind the app need the same scrutiny as the app, on a regular cadence and again after each major change.
How Ostorlab helps
Ostorlab intercepts the app's traffic, even with TLS pinning, and tests the APIs for broken authorization (BOLA, BFLA, IDOR), misuse of tokens and sessions, and abuse such as enumeration, replay and automation, with request and response evidence for each finding.
What stays with you
API gateways, the API inventory, logging and monitoring, and API lifecycle management.
- CBK CORF, Chapter 4, 5.8.1.3, 5.8.1.6, 5.8.1.7 and 5.9.1.6
Build security into development and releases
What the text says
Entities must follow a DevSecOps approach, adopt secure coding practices such as OWASP to address common weaknesses like the CWE Top 25, and keep an up-to-date Software Bill of Materials for all software, including software from third-party suppliers. Testing before a change reaches production must cover security testing, source code reviews where applicable, penetration testing and vulnerability assessment.
Source:CBK CORF, Chapter 4, 5.8.1.3, 5.8.1.6, 5.8.1.7 and 5.9.1.6
What it means for your mobile app
Each release of the app should pass security testing before it reaches the store, and you should know which third-party components it ships.
How Ostorlab helps
Automated scans run from your CI/CD pipeline on every build. SCA lists the SDKs and native libraries in each release with their versions, maps them to known vulnerabilities and tracks their closure from release to release.
What stays with you
Secure design reviews, manual code reviews, segregation of duties and change approval, including CBK approval for major changes.
- CBK CORF, Chapter 4, 5.13.1.2, 5.13.1.5 to 5.13.1.7
Track vulnerabilities to closure and validate the fix
What the text says
Vulnerability assessments of networks, systems and applications must run periodically or whenever significant changes occur. Findings must be documented and tracked until closure, and entities must validate remediation to confirm the gaps are addressed. Entities must use external attack surface management for public-facing assets.
What it means for your mobile app
Finding issues is not enough. You need a record that each one was fixed and retested, and a view of the apps you expose.
How Ostorlab helps
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. Attack surface discovery helps you find the apps and assets you expose.
What stays with you
Remediation timelines, patch management and the quarterly report to the Board.
- CBK Circular No. (2/BS, IBS/534/2023)
Protect customers from electronic fraud
What the text says
When a customer adds a new beneficiary through internet or mobile banking, an OTP SMS must be sent, the customer must be notified, and the beneficiary must not be activated for at least 12 hours unless the customer confirms. Unrecognised devices must be verified by phone before any transaction. Banks must prevent use of the app when remote-control apps such as AnyDesk are installed, and generate security codes so transactions cannot be made from another device.
What it means for your mobile app
The beneficiary delay, the new-device checks and the device-bound security codes are business logic. They have to hold on the server, not just in the app's screens.
How Ostorlab helps
Ostorlab tests the fraud-relevant controls inside the app and its APIs: authentication, step-up checks, session handling, device protections and the business logic behind payments.
What stays with you
Detecting remote-control apps, phone verification, transaction monitoring and customer awareness.
Summary of the public CBK texts, checked on 27 September 2026. The electronic payment circulars are English translations published by the CBK for information; the Arabic text is the legal version. This page is not legal advice.
CBK CORF, control by control
The mobile and API controls in the CORF, how Ostorlab tests them in your app and its APIs, and the evidence you can keep.
| Control | How Ostorlab helps | Evidence you keep |
|---|---|---|
| Vulnerability assessments and penetration tests of the mobile appCORF 5.8.2.2, 8.3.1.14 | AI-agent pentest of the app and its APIs, behind login, on the build you ship. Details | A working exploit you can replay for each AI-agent finding, and a coverage heatmap |
| Blocking rooted and jailbroken devicesCORF 8.3.1.7, 8.1.3.3 | Runs the app in rooted and jailbroken environments and attempts to bypass root and jailbreak detection. Details | Hardening score, and bypass evidence for each protection that failed |
| MFA for critical actions and changes to contact detailsCORF 8.3.1.3, 8.1.3.5 | Logs in with one-time codes and tests MFA enforcement and step-up flows, and the API calls behind them. Details | Findings on login and step-up flows, with reproduction steps |
| Five-minute session timeout, two-minute OTPs, three failed attemptsCORF 8.3.1.1, 8.3.1.2, 8.1.3.1 | Tests login and logout, token refresh, timeouts and session invalidation. Details | Session and token findings, with request and response logs |
| Encryption of data stored on the deviceCORF 8.3.1.8 | Looks for tokens and personal data in storage, caches, logs and screenshots, and checks transport protections. Details | File system evidence showing what was written, where and when |
| API authentication, access control, rate limiting and testingCORF 5.8.3.1 to 5.8.3.8, 8.3.2.7 | Intercepts traffic even with TLS pinning and tests authorization, token misuse and abuse such as enumeration and replay. Details | Request and response evidence for each API finding |
| Security testing before releaseCORF 5.8.1.6, 5.9.1.6 | Mobile SAST on the binary and Mobile DAST on the running app, before release. Details | Findings with decompiled source context, traffic, stack traces and screenshots |
| Software Bill of Materials for each releaseCORF 5.8.1.3 | Lists the SDKs and native libraries in each release with their versions, and shows which backends the app and its SDKs talk to. Details | Component identity, version and location in the app bundle, per release |
| Tracking findings to closure and validating remediationCORF 5.13.1.5, 5.13.1.7 | Groups findings into tickets in the platform or in Jira and ServiceNow, and retests after the fix. | Ticket history and retest result for each finding |
| Hardcoded credentials in the appCORF 8.1.3.2 | Finds API keys, tokens and credentials in the app package and validates whether they work. Details | Validated secrets, with the permissions and services they expose |
Ostorlab tests controls in the app and its APIs. Governance, risk profiles and self-assessments, SOC monitoring, fraud operations, business continuity, third-party and cloud risk management, and reporting to the CBK stay with your teams.
CORF mobile controls to test in your app
A practical list for security and compliance teams preparing for a CORF assessment.
Rooted and jailbroken devices
Run the app on rooted and jailbroken devices, try to hide the device state, and confirm the app blocks installation or use.
Session and OTP settings
Verify the five-minute inactivity timeout, the ban on concurrent sessions, the two-minute OTP lifetime and the three-attempt lockout.
MFA on critical actions
Check that account activation, transfers, bill payments, new beneficiaries and contact-detail changes all require strong MFA, enforced by the server.
New beneficiaries and new devices
Confirm the 12-hour beneficiary delay and the new-device checks from Circular 534/2023 cannot be skipped through the API.
APIs behind the app
Test authorization, input validation and rate limiting on every account and payment API, and again after each major change.
Data left on the device
Look for unencrypted tokens and personal data in storage, caches, logs and screenshots, and for credentials hardcoded in the app.
SBOM for each release
Keep an up-to-date list of the SDKs and native libraries each release ships, with known vulnerabilities and their closure.
Evidence for the assessment
Keep results, tickets and retests for each release, to show vulnerabilities were tracked to closure and remediation was validated.
A suggested list, not a CBK template. This is not legal advice.
The capabilities behind this page
Each one has its own page with the details.
- Mobile Agentic Deep ScanAI agents pentest the store build on every release, with a working exploit you can replay for each AI-agent finding.Learn more
- Mobile Shielding ScanTest root and jailbreak detection, anti-tampering and pinning at runtime, and see which protections held and which were bypassed.Learn more
- Authenticated testingTest login, one-time codes and step-up flows with your test accounts.Learn more
- API and backend testingIntercept app traffic even with TLS pinning, then test the APIs and backends behind accounts and payments.Learn more
- Mobile SASTBinary-based static analysis of APK, AAB and IPA files, with taint analysis across the app and its embedded SDKs.Learn more
- SCA and SBOMFind vulnerable dependencies, including statically compiled native libraries, and track their closure release after release.Learn more
- Bring your own AI keyRun AI-agent scans on your own AI provider key with a spend cap per scan, so usage follows your internal policies.Learn more
- On-premises scanningScan staging apps, APIs and repositories behind your firewall or VPN, on infrastructure you control.Learn more
Trusted by banks and fintechs, including
Sources
The official texts this page is based on, checked on 27 September 2026.
- Cyber and Operational Resilience Framework for All Local Banks and Financial Institutions (CORF)Central Bank of Kuwait, Version 1.0, first release 3 December 2025. Applies to all CBK Regulated Entities; Chapter 4 holds the cyber resilience baselines on applications, APIs, vulnerability management and payments security
- CBK Launches the Cyber & Operational Resilience Framework for Local Banks and Financial InstitutionsCentral Bank of Kuwait press release, 3 December 2025
- Cybersecurity Framework for Kuwaiti Banking SectorCentral Bank of Kuwait, Version 1.0, January 2020. The earlier framework the CORF builds on
- Circular No. (2/BS, BS, IBS/415/2018): Instructions for Regulation of the Electronic Payment of FundsCentral Bank of Kuwait, 23 December 2018, issued under Resolution No. 44/430 of 2018. English translation for information; the Arabic text is the legal version
- Circulars for Regulating the Electronic Payment of Funds, including Circular No. (2/BS, IBS/534/2023) on Measures for Protection of Customers from Electronic FraudCentral Bank of Kuwait, Chapter Two of the e-payment instructions. Circular 534/2023 is dated 18 September 2023 and covers beneficiaries, new devices and remote-control apps. English translation for information
Frequently asked questions
Straight answers on coverage, setup, and how results reach your team.
Can't find your answer? Book a demo or contact us.
Test your mobile banking app against the CORF baselines
Start with a free scan of your app from the store, or book a demo to run shielding and logged-in tests with our team.