OSFI B-13: test your mobile banking app before and after every release.
Guideline B-13 asks federally regulated financial institutions to adopt secure-by-design practices for the applications and APIs they develop, to scan and test systems before release into production, to rank and remediate vulnerabilities on risk-based timelines, and to implement multi-factor authentication. Guideline B-10 extends the same expectations to the SDKs, cloud services and vendors behind your app. Ostorlab tests your app and the APIs behind it, behind login, on every release.
- Assesses the mobile app and the APIs it calls, on the build your customers download
- Tests login, one-time codes, step-up checks and session handling with your test accounts
- Lists the SDKs and native libraries in each release and maps them to known vulnerabilities
- Proves each finding with a replayable exploit or request and response evidence
- Who it applies to
- Federally regulated financial institutions (FRFIs): banks, trust and loan companies, insurers and foreign bank branches in Canada
- Key dates
- B-13 effective 1 January 2024; B-10 effective 1 May 2024; E-21 full adherence by 1 September 2026
- Focus
- Secure development and testing before release, vulnerability remediation, MFA, SDK and third-party risk, and 24-hour incident reporting
- Main reference
- OSFI Guideline B-13, Technology and Cyber Risk Management
The Canadian texts behind your mobile channel
Federal financial institution rules and federal and Quebec privacy law apply to the same app. The dates below are for the texts cited on this page.
- 1 November 2018
PIPEDA breach reporting
Mandatory breach reporting comes into force under PIPEDA: report to the Privacy Commissioner and notify individuals when a breach of security safeguards creates a real risk of significant harm, and keep a record of every breach.
- 13 August 2021
Incident reporting advisory
OSFI's updated Technology and Cyber Security Incident Reporting Advisory takes effect: report a technology or cyber security incident to OSFI's Technology Risk Division and to your Lead Supervisor within 24 hours, or sooner if possible.
- July 2022
Guideline B-13
OSFI publishes the final Technology and Cyber Risk Management guideline. It applies from 1 January 2024 and covers governance and risk management, technology operations and resilience, and cyber security.
- 21 April 2023
I-CRT framework
OSFI releases the Intelligence-led Cyber Resilience Testing framework. OSFI recommends that systemically important banks and internationally active insurance groups run an I-CRT assessment at least once in each three-year supervisory cycle, beginning in 2023.
- 1 May 2024
Guideline B-10 effective
The Third-Party Risk Management guideline, dated 30 April 2023, takes effect. It covers due diligence, contracting, data security, audit rights and technology and cyber risk in third-party arrangements.
- 22 August 2024
Guideline E-21
OSFI publishes the final Operational Risk Management and Resilience guideline. Sections 1 and 2 apply immediately; section 4 is expected by 1 September 2025 and full adherence by 1 September 2026.
- 22 September 2024
Quebec Law 25, final phase
The right to data portability takes effect. The confidentiality incident regime, including notification to the Commission and affected persons and the incident register, and the privacy officer requirement, have applied since 22 September 2022; most other obligations, including privacy impact assessments and consent rules, since 22 September 2023 (French text).
- April 2026
Frontier AI bulletin
OSFI's Technology Risk Bulletin on frontier artificial intelligence says the time to identify and exploit vulnerabilities has compressed, and points institutions back to B-13, B-10 and E-21 for patching, incident response and third-party oversight.
The OSFI expectations, applied to your mobile app
For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team.
- OSFI Guideline B-13, 3.2.1 and 2.4.2
Build security into the app and its APIs
What the text says
Adopt secure-by-design practices to safeguard technology assets. Security defence controls should aim to be preventive where feasible, and standard security controls should be applied end to end, starting at the design stage, to applications, micro-services and application programming interfaces developed by the institution. Security requirements and expectations should be embedded in each phase of the system development life cycle, including in Agile development methods.
What it means for your mobile app
The mobile app is an application you develop and an external-facing channel. Secure design, review and testing have to be part of the way each release is built, not a step bolted on at the end.
How Ostorlab helps
Mobile SAST analyses the APK, AAB or IPA directly, with no source code needed, including taint analysis across embedded SDKs, and runs from your CI/CD pipeline on every build.
What stays with you
Secure coding standards, control gates in the SDLC, design reviews and release approval.
- OSFI Guideline B-13, 3.2.9
Scan and test applications before release
What the text says
Where feasible, use static and/or dynamic scanning and testing capabilities to ensure that new systems and applications, and changes to existing ones, are assessed for vulnerabilities before they are released into the production environment. Where development and operations practices are combined through a continuous and automated pipeline, implement security controls that maintain security.
Source:OSFI Guideline B-13, 3.2.9
What it means for your mobile app
Every store release is a change to a production system. The assessment has to happen before the build reaches customers, ideally on every build in the pipeline.
How Ostorlab helps
Mobile SAST and Mobile DAST run automated scans from your CI/CD pipeline on every build, and Ostorlab monitors store releases without manual triggers. Both work on the binary, with no source code needed.
What stays with you
Choosing the pipeline gates, defining what blocks a release, and approving what ships.
- OSFI Guideline B-13, 3.1.3
Assess and rank vulnerabilities regularly
What the text says
Establish processes to conduct regular vulnerability assessments of technology assets, including but not limited to network devices, systems and applications. The processes should articulate the frequency with which scans and assessments are conducted, and rank cyber vulnerabilities and threats by the severity of the threat and the risk exposure of the asset using a standard risk measurement methodology, considering the cumulative impact of vulnerabilities that could present a high risk when combined.
Source:OSFI Guideline B-13, 3.1.3
What it means for your mobile app
The mobile app and the APIs it calls belong in that assessment, with a named frequency, a severity rating for each finding and a view of how findings combine.
How Ostorlab helps
An AI-agent pentest tests the app and its APIs behind login, on the build you ship, with a working exploit you can replay for each AI-agent finding and a coverage heatmap for the release.
What stays with you
The assessment methodology, the risk scoring you use and the treatment of findings outside the app.
- OSFI Guideline B-13, 3.1.2; OSFI I-CRT Framework, April 2023
Run penetration tests and prepare for I-CRT
What the text says
Set defined triggers and minimum frequencies for intelligence-led threat assessments, and regularly perform tests and exercises to identify vulnerabilities or control gaps in the cyber security programme, such as penetration testing and red teaming, using an intelligence-led approach, with the scope and potential impacts clearly defined and risk mitigations applied. Separately, OSFI's I-CRT framework is a regulatory-led assessment for systemically important banks and internationally active insurance groups that mimics a sophisticated threat actor using targeted threat intelligence, recommended at least once in each three-year supervisory cycle.
Source:OSFI Guideline B-13, 3.1.2; OSFI I-CRT Framework, April 2023
What it means for your mobile app
Penetration testing and red teaming are B-13 expectations with triggers you define. I-CRT is a different, broader exercise, led by OSFI and aimed at larger institutions.
How Ostorlab helps
Ostorlab does not run red teaming or I-CRT. It helps you go into either exercise with known app and API issues already fixed, and retests the app and API items of a remediation plan afterwards.
What stays with you
Scoping and running penetration tests and red teaming, the I-CRT assessment with OSFI, and the choice of providers.
- OSFI Guideline B-13, 3.2.6 and 2.6; OSFI Technology Risk Bulletin on frontier AI, April 2026
Patch and remediate on risk-based timelines
What the text says
Maintain capabilities for timely, risk-based patching of vulnerabilities in vendor software and internal applications, considering the severity of the threat and the exposure of the system. Apply patches at the earliest opportunity, commensurate with risk and in line with established timelines, implement compensating controls when remediation options are not available, such as for zero-day attacks, and regularly monitor and report on patching status and remediation against defined timelines, including any backlog and exceptions. In April 2026, OSFI's Technology Risk Bulletin on frontier artificial intelligence said the timeframe to identify and exploit vulnerabilities has compressed, and pointed institutions back to B-13, B-10 and E-21.
Source:OSFI Guideline B-13, 3.2.6 and 2.6; OSFI Technology Risk Bulletin on frontier AI, April 2026
What it means for your mobile app
A fix deadline has to be defensible: severity, exposure, evidence of closure, and a documented exception when you accept the risk instead.
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, so the backlog and the closure record come from the platform.
What stays with you
The patching calendar, compensating controls, risk acceptance decisions and reporting to senior management.
- OSFI Guideline B-13, 3.2.7
Enforce MFA on external-facing channels
What the text says
Implement risk-based identity and access controls, including multi-factor authentication and privileged access management. Where feasible, implement MFA across external-facing channels and privileged accounts, including customers, employees and third parties, enforce the principle of least privilege, conduct regular attestation of access, manage privileged account credentials in a secure vault, and log and monitor account activity as part of continuous security monitoring.
Source:OSFI Guideline B-13, 3.2.7
What it means for your mobile app
The mobile app is an external-facing channel. MFA and access controls have to be enforced by the backend, including when the app or an attacker skips a step.
How Ostorlab helps
Authenticated testing covers login and logout, token refresh, timeouts, session invalidation and MFA enforcement, including step-up flows, together with the API calls behind them.
What stays with you
Choosing and deploying the MFA methods, privileged access management, and continuous monitoring of account activity.
- OSFI Guideline B-13, 3.1.4 and 3.2.5
Protect data throughout its life cycle
What the text says
Starting with clear information classification, design and implement risk-based controls for the protection of data throughout its life cycle, including data loss prevention capabilities and controls for data at rest, data in transit and data in use. Identify, classify and protect structured and unstructured data based on its confidentiality classification, and perform periodic discovery scans to identify changes and deviations from the controls that protect data from unauthorised access.
What it means for your mobile app
Passwords, tokens and personal data should not sit in clear text on the phone or travel to the backend without protection, whatever the data classification says.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, checks transport protections, and finds credentials left in the app package.
What stays with you
Data classification, key management, data loss prevention tooling and retention.
- OSFI Guideline B-10, 2.2.2, 2.3.2, 2.3.3 and 4.2
Manage the SDKs and vendors behind the app
What the text says
Undertake due diligence proportionate to the risk and criticality of each third-party arrangement, before entering it and on an ongoing basis, covering the third party's capacity to manage technology and cyber risks in line with B-13 and to give you enough information to meet your incident reporting requirements. Set out each party's responsibilities for the confidentiality, availability and integrity of records and data, keep the right to conduct or commission an independent audit, and, where risk or criticality requires it, ensure that the third party complies with your standards or recognised industry standards, notably for access management, data security and protection. Use a range of audit and information gathering methods.
What it means for your mobile app
A mobile release can bundle dozens of third-party SDKs, each talking to its own backend. They are third-party arrangements inside your app, and they belong in the same due diligence and audit view.
How Ostorlab helps
Ostorlab lists the SDKs and native libraries in each release with their versions and their location in the app bundle, maps them to known vulnerabilities, and shows which backends the app and its SDKs talk to.
What stays with you
Contracts, due diligence files, audit rights and the decision to keep or replace a vendor.
- OSFI Technology and Cyber Security Incident Reporting Advisory, 13 August 2021
Report incidents to OSFI within 24 hours
What the text says
Report a technology or cyber security incident to OSFI's Technology Risk Division and to your Lead Supervisor within 24 hours, or sooner if possible, using the incident reporting form, and keep OSFI updated until the incident is contained or resolved, including short-term and long-term remediation actions and plans. After containment, recovery and closure, report on the post-incident review and lessons learned. A technology or cyber security incident is one that has an impact, or the potential to have an impact, on the institution's operations, including the confidentiality, integrity or availability of its systems and information.
Source:OSFI Technology and Cyber Security Incident Reporting Advisory, 13 August 2021
What it means for your mobile app
Detection and evidence speed matter. To report within 24 hours, you need to know what happened, which systems and data were affected, and what the app and its APIs exposed.
How Ostorlab helps
Ostorlab gives you a working exploit and request and response evidence for each finding, and retests after the fix, so you can scope the affected flows, produce the post-incident review and show closure.
What stays with you
The reporting itself, incident response, communications, and the post-incident review with OSFI.
- PIPEDA, Schedule 1 clause 4.7 and sections 10.1 to 10.3; Loi 25, Quebec (French text)
Meet the privacy duties for the app's data
What the text says
PIPEDA requires personal information to be protected by security safeguards appropriate to its sensitivity, protecting it against loss or theft as well as unauthorised access, disclosure, copying, use or modification, with physical, organizational and technological measures, and requires organizations to report to the Privacy Commissioner and notify individuals when a breach of security safeguards creates a real risk of significant harm, and to keep a record of every breach. In Quebec, Law 25 requires enterprises to take security measures to protect personal information, to notify the Commission d'accès à l'information and the persons concerned of a confidentiality incident presenting a risk of serious harm, to keep an incident register, to publish the contact details of a privacy officer, to run privacy impact assessments for information system projects, and, since 22 September 2024, to provide data portability on request (French text).
Source:PIPEDA, Schedule 1 clause 4.7 and sections 10.1 to 10.3; Loi 25, Quebec (French text)
What it means for your mobile app
Findings such as personal data left in logs or caches, or weak transport, are privacy incidents waiting to happen. Both regimes ask you to protect the data and to be able to account for it.
How Ostorlab helps
Ostorlab tests the technical controls in the app and its APIs: what is written to the device, what travels unprotected, and who can reach what through the APIs.
What stays with you
Privacy policies, consent, privacy impact assessments, breach notification and the incident register.
Summary of public OSFI texts, PIPEDA and Quebec Law 25 material, checked on 27 September 2026. OSFI guidelines set supervisory expectations. The Quebec material is summarised from the Commission d'accès à l'information's French pages. This page is not legal advice.
OSFI expectations, control by control
The controls the Canadian texts point to, how Ostorlab tests them in your app and its APIs, and the evidence you can keep.
| Control | How Ostorlab helps | Evidence you keep |
|---|---|---|
| Secure-by-design controls for apps and APIsB-13 3.2.1 | Intercepts the app's traffic even with TLS pinning, and tests authorization, input handling and business logic in the APIs behind login. Details | Request and response evidence for each API finding |
| Static and dynamic testing before releaseB-13 3.2.9 | Mobile SAST on the binary and Mobile DAST on the running app, from CI/CD on every build. Details | Findings with decompiled source context, traffic, stack traces and screenshots |
| Vulnerability assessment of the app and its APIsB-13 3.1.3 | 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 |
| Penetration testing, red teaming and I-CRT preparationB-13 3.1.2; I-CRT | Tests the app and the APIs behind login, helps you fix known issues before an I-CRT, and retests the app and API items of a remediation plan. | Findings with reproduction steps, and retest results after the fix |
| Vendor software, components and fix deadlinesB-13 3.2.6, 2.6 | SCA fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Details | Mapped vulnerabilities with upgrade or replace recommendations, and closure tracked across releases |
| MFA on external-facing channelsB-13 3.2.7 | 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 |
| Sessions, tokens and privileged accessB-13 3.2.7 | Tests login and logout, token refresh, timeouts and session invalidation. Details | Session and token findings, with request and response logs |
| Data protection on the device and in transitB-13 3.1.4, 3.2.5 | 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 |
| Third-party SDKs and vendor componentsB-10 2.2.2, 4.2 | 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 |
| Credentials embedded in the app packageB-13 3.2.5 | 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. Incident detection and reporting to OSFI, red teaming and I-CRT, fraud monitoring, backups and recovery, governance, contracts and privacy compliance stay with your teams.
OSFI controls to test in your mobile app
A practical list for security and technology risk teams, based on B-13, B-10 and the incident reporting advisory.
App and API in the SDLC
Add the mobile app to the secure development life cycle: security requirements at design, and scanning as a control gate before release.
Scan every build
Run Mobile SAST and DAST from the pipeline on every build, and scan each store release, not only the version you tested last quarter.
Ranked assessments
Include the app and the APIs it calls in the regular vulnerability assessment, with a named frequency and a severity rating per finding.
Fix deadlines
Set patch deadlines by severity and exposure, keep evidence of closure, and record any exception you accept.
MFA and sessions
Verify that MFA, session expiry and token invalidation are enforced on the server for the app's key operations.
Data on the device
Check storage, caches, logs and screenshots for personal data and tokens, and check transport protections and the app package for secrets.
Third parties and SDKs
Keep a versioned inventory of SDKs and libraries, and hold vendor security evidence and audit rights for the high-risk ones.
Evidence for incidents and exams
Keep exploit evidence and retest results with each release, ready for post-incident reviews, privacy duties and OSFI supervision.
A suggested list, not an OSFI 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
- 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
- Mobile Shielding ScanTest root and jailbreak detection, anti-tampering and pinning at runtime, and see which protections held and which were bypassed.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.
- Guideline B-13: Technology and Cyber Risk ManagementOSFI, published July 2022, effective 1 January 2024. Three domains: governance and risk management, technology operations and resilience, and cyber security, including system development life cycle (2.4), change and release management (2.5), patch management (2.6) and cyber security (3.1 and 3.2)
- Guideline B-10: Third-Party Risk ManagementOSFI, dated 30 April 2023, effective 1 May 2024. Due diligence (2.2.2), data security and controls (2.3.2), information rights and audit (2.3.3), and technology and cyber risk in third-party arrangements (section 4)
- Guideline E-21: Operational Risk Management and ResilienceOSFI, dated 22 August 2024. Sections 1 and 2 effective immediately, section 4 expected by 1 September 2025, full adherence by 1 September 2026. Change management (4.4), scenario testing (3.3) and data risk management (4.7)
- Technology and Cyber Security Incident ReportingOSFI advisory, dated 13 August 2021, effective the same day. Report to the Technology Risk Division and the Lead Supervisor within 24 hours, or sooner if possible. Replaces the January 2019 advisory
- OSFI's Intelligence-led Cyber Resilience Testing (I-CRT) FrameworkOSFI, released 21 April 2023. A regulatory-led, intelligence-led red team assessment of a FRFI's technology assets and services supporting critical business functions, applying to systemically important banks and internationally active insurance groups, at least once per three-year supervisory cycle beginning in 2023
- Personal Information Protection and Electronic Documents Act (PIPEDA)Justice Canada consolidation, S.C. 2000, c. 5. Schedule 1 clause 4.7 (safeguards) and sections 10.1 to 10.3 (breach of security safeguards), in force 1 November 2018 with the Breach of Security Safeguards Regulations, SOR/2018-64
- Principaux changements apportés par la Loi 25Commission d'accès à l'information du Québec (French text). Security measures, privacy officer, privacy impact assessments, confidentiality incident notification and register, transfers outside Quebec, and data portability since 22 September 2024. The companion page Incidents de confidentialité et mesures de sécurité covers security measures and incident handling
- Technology Risk Bulletin: Frontier Artificial Intelligence: Implications for Technology, Cyber Security, and Operational ResilienceOSFI, April 2026. Points institutions to B-13, B-10 and E-21 and says the timeframe to identify and exploit vulnerabilities has compressed. The bulletin index also lists a July 2026 bulletin on generative and agentic AI
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 OSFI expectations
Start with a free scan of your app from the store, or book a demo to run logged-in tests of your app and APIs with our team.