FSA cybersecurity guidelines: assess your mobile banking app before and after every release.

1. 01

   FSA Guidelines on Cybersecurity for the Financial Sector, 2.2.4, fundamental measures

   Assess mobile apps and public APIs regularly

   What the text says

   Regularly conduct vulnerability assessments and penetration tests, taking into account risk level and system importance. Define scope, frequency and timing, including before systems are released. For publicly accessible websites such as internet banking sites and public APIs, conduct both platform and web application assessments. Conduct vulnerability assessments for mobile applications. Prioritise findings, set response deadlines, and report significant findings promptly to senior management.

   Source:FSA Guidelines on Cybersecurity for the Financial Sector, 2.2.4, fundamental measures

   What it means for your mobile app

   Mobile app assessment is a named fundamental measure. The app, and the APIs it calls, should be assessed before release and on a regular cadence.

   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 tests the app and its APIs behind login, with a working exploit you can replay for each AI-agent finding.

   What stays with you

   Setting the frequency, platform assessments of servers and VPN equipment, and reporting to senior management.

2. 02

   FSA Guidelines on Cybersecurity for the Financial Sector, 2.2.4, recommended measures (b) to (d)

   Consider threat-led penetration testing

   What the text says

   As a recommended measure, regularly conduct threat-led penetration testing (TLPT), with vendors that have the necessary experience and skills, realistic threat scenarios based on threat intelligence, and tests in production without prior notice to the Blue Team. Periodically review penetration test methods and results, and consider changing test vendors for fresh and independent perspectives.

   Source:FSA Guidelines on Cybersecurity for the Financial Sector, 2.2.4, recommended measures (b) to (d)

   What it means for your mobile app

   TLPT is expected mainly of major institutions. It tests your defences as a whole, not just the app, and works best when known app and API issues are already fixed.

   How Ostorlab helps

   Ostorlab does not run TLPT and does not replace it. It helps you go into a TLPT with known app and API issues already fixed, and retest the app and API items of your remediation plan afterwards.

   What stays with you

   Scoping and running TLPT, choosing the vendor and evaluating the Blue Team.

3. 03

   FSA Guidelines on Cybersecurity for the Financial Sector, 2.2.3; FSA and Bank of Japan request on Frontier AI, 22 May 2026

   Manage vulnerabilities with deadlines

   What the text says

   Set procedures for managing vulnerabilities in hardware and software: sources of vulnerability information, evaluation of severity and impact, response methods and deadlines, and exceptions. Set deadlines for patches based on system criticality, risk and severity, keep records of implementation, and get formal approval from senior management when a fix is exceptionally not applied. In May 2026 the FSA and the Bank of Japan asked institutions to prioritise externally accessible systems supporting critical services, such as internet banking, and noted that the risks extend to third-party software including open-source components.

   Source:FSA Guidelines on Cybersecurity for the Financial Sector, 2.2.3; FSA and Bank of Japan request on Frontier AI, 22 May 2026

   What it means for your mobile app

   The libraries and SDKs inside your app are software you ship. Each one needs a known version, a severity when a vulnerability appears, and a fix deadline you can prove.

   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 and risk acceptance decisions.

4. 04

   FSA Guidelines on Cybersecurity for the Financial Sector, 2.3.4.3; Comprehensive Guidelines for Supervision of Major Banks, III-3-7-1-2(6)

   Build security in and test before and after release

   What the text says

   Implement security by design by incorporating security requirements from the planning and design stages of financial products and services. As recommended measures, define secure coding standards, conduct vulnerability assessments of application software both before and after release on a regular basis, and use tools such as source code analysis tools to find vulnerabilities early. The supervisory guidelines also ask banks to draw up test plans and test adequately when developing systems.

   Source:FSA Guidelines on Cybersecurity for the Financial Sector, 2.3.4.3; Comprehensive Guidelines for Supervision of Major Banks, III-3-7-1-2(6)

   What it means for your mobile app

   Every app release is a change to an internet-facing channel. Automated testing in the pipeline covers the before; scans of store releases cover the after.

   How Ostorlab helps

   Ostorlab runs automated scans from your CI/CD pipeline on every build and monitors store releases without manual triggers. Mobile SAST works on the APK, AAB or IPA, with no source code needed.

   What stays with you

   Security requirements, secure coding standards, manual reviews and release approval.

5. 05

   FSA Guidelines on Cybersecurity for the Financial Sector, 2.2.1.2 and 2.6

   Know what is inside each release

   What the text says

   Keep ledgers of hardware and software, including version information for software. As a recommended measure, prepare a Software Bill of Materials (SBOM) for software developed in-house. Manage cybersecurity risks across the supply chain, and identify and assess third parties based on their role, the sensitive information they handle and their system connectivity.

   Source:FSA Guidelines on Cybersecurity for the Financial Sector, 2.2.1.2 and 2.6

   What it means for your mobile app

   A mobile banking app bundles third-party SDKs that talk to their own backends. They belong in your inventory and your third-party risk view.

   How Ostorlab helps

   Ostorlab lists the SDKs and native libraries in each release with their versions and their location in the app bundle, and shows what the app and its SDKs exchange with backends over the network.

   What stays with you

   The asset ledger, third-party due diligence and contracts.

6. 06

   FSA Guidelines on Cybersecurity for the Financial Sector, 2.3.1 (3), (5) and (7)

   Manage authentication and credentials

   What the text says

   Properly manage device IDs and authentication credentials, including credentials embedded in APIs. Set authentication requirements, such as multi-factor or risk-based authentication, based on the criticality of systems and information assets. Ensure confidentiality, integrity and authenticity in authentication and authorisation across systems and security boundaries, including single sign-on and external authentication integrations.

   Source:FSA Guidelines on Cybersecurity for the Financial Sector, 2.3.1 (3), (5) and (7)

   What it means for your mobile app

   API keys and tokens left in the app package are credentials anyone can extract. Authorisation between the app, the backend and external identity 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. It intercepts the app's traffic, even with TLS pinning, 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 and physical access controls.

7. 07

   Comprehensive Guidelines for Supervision of Major Banks, III-3-8-2(2), as amended on 27 February 2026 (Japanese text)

   Phishing-resistant MFA and account lock for internet banking

   What the text says

   Banks should implement phishing-resistant multi-factor authentication, such as passkeys or PKI-based authentication, for key operations such as login and withdrawals, and make it mandatory by default. Where an alternative MFA is offered in the meantime, customers should be told the schedule, and detection such as behaviour analysis and login notifications should be strengthened. Banks should also send notifications to detect unauthorised logins and transactions, and automatically lock accounts after consecutive authentication failures.

   Source:Comprehensive Guidelines for Supervision of Major Banks, III-3-8-2(2), as amended on 27 February 2026 (Japanese text)

   What it means for your mobile app

   The second factor has to be enforced by the server on every key operation, including when the app or an attacker skips a step. Lockout and notifications are behaviours you can test.

   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 passkeys or PKI, behaviour detection, and tracking the rate of customers who opt out.

8. 08

   Comprehensive Guidelines for Supervision of Major Banks, III-3-7-1-2(5) (Japanese text)

   Guard contact details used for authentication

   What the text says

   To prevent misuse of internet banking, banks should have appropriate procedures so that phone numbers, email addresses and other information used to notify or authenticate depositors cannot be fraudulently registered or changed. For non-face-to-face transactions, banks should secure the channel as set out in the internet banking section.

   Source:Comprehensive Guidelines for Supervision of Major Banks, III-3-7-1-2(5) (Japanese text)

   What it means for your mobile app

   Changing a phone number or email address in the app is a classic step in account takeover. The change has to require strong authentication, enforced by the backend.

   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

   The change procedures themselves and customer notification channels.

9. 09

   FSA Guidelines on Cybersecurity for the Financial Sector, 2.3.3; Comprehensive Guidelines for Supervision of Major Banks, III-3-7-1-2(4)

   Protect customer data

   What the text says

   Classify data by importance and protect it according to data management policies, for example with encryption, authentication, data masking and access control, and manage encryption keys throughout their lifecycle. The supervisory guidelines ask banks to set encryption and masking rules for confidential information such as PINs, passwords and credit card data.

   Source:FSA Guidelines on Cybersecurity for the Financial Sector, 2.3.3; Comprehensive Guidelines for Supervision of Major Banks, III-3-7-1-2(4)

   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.

   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, key management, backups and data loss prevention.

Summary of public FSA texts, checked on 27 September 2026. Supervisory guideline items are summarised from the Japanese text. FISC Security Guidelines are sold by FISC and not quoted here. This page is not legal advice.