Why API Security Belongs in ECB Cyber Action Plans

In its July 7, 2026, supervisory letter, the ECB mandates that significant financial institutions take direct ownership of this risk by submitting detailed action plans to their Joint Supervisory Teams (JSTs) by October 31, 2026. Plans should specify measures, resources, responsibilities, and implementation timelines. Note that this is a submission deadline, not a requirement to finish every improvement by that date.

The letter builds on the Digital Operational Resilience Act (DORA) and existing cyber risk strategies. Annex 1 includes APIs among the entities that can support Zero Trust principles and defense in depth through continuous verification. It also emphasizes vulnerability management, monitoring, third-party risk, and response and recovery.

Our recommendation is to turn that API relevance into concrete work: Establish which interfaces are exposed, prioritize their risks, and validate the controls protecting them.

APIs connect banking applications to account information, payment services, partner systems, and internal workflows. Their structured requests and responses give attackers a repeatable way to probe for weaknesses. AI-assisted tooling can accelerate this work, increasing pressure on teams to address broken authorization, data exposure, misconfiguration, and business logic abuse.

Shadow APIs fall outside of approved inventory and the security team’s visibility. Zombie APIs remain accessible after they have become outdated or deprecated. Either can miss the testing, policy updates, and monitoring applied to current services. OWASP API9:2023 Improper Inventory Management identifies incomplete inventories and outdated API versions as security risks. Removing an endpoint from documentation does not make it inaccessible.

For example, an older account statement API might accept a valid login but fail to verify whether the requested statement actually belongs to that user. By simply changing a record identifier, an attacker could expose another customer's information, a vulnerability known as broken object level authorization (BOLA). A request can be correctly formatted and remain below rate limits while violating access rules, so controls focused only on request format, authentication, or volume may miss that abuse.

Akamai API Security combines discovery from runtime traffic, source-code repositories, specifications, and supported infrastructure integrations (Figure). This helps banks identify APIs that a gateway-only inventory or documentation review may miss, including internal service-to-service APIs. Coverage depends on the data sources and environments connected to the platform.

Akamai API Security assesses posture and identifies which APIs are handling sensitive data, helping teams prioritize weaknesses such as authentication gaps or misconfigurations. Exposure and business impact should guide the response. 

An internet-facing API serving financial records may warrant earlier remediation than an isolated test endpoint with no production data. For a deprecated API, the right action may be a controlled retirement after confirming that legitimate consumers have migrated.

With Active Testing, organizations can test existing APIs to identify authorization weaknesses and business logic abuse. Teams can run tests before production, on demand, or within continuous integration and continuous delivery (CI/CD) workflows, then validate fixes before release. Source-code discovery identifies interfaces, and dynamic testing provides evidence of how those interfaces behave under attack.

Whenever possible, Akamai connects findings to repository, file-path, and developer context. This gives application teams a clearer starting point for remediation and reduces the time spent locating the code behind an affected API, ensuring that development velocity is not compromised by security bottlenecks.

​​On their own, discovery and testing are not enough. Production APIs need monitoring even after they pass security tests. Akamai API Security analyzes API behavior to identify anomalous use, sensitive-data exposure, and business logic abuse, including activity involving valid credentials and legitimate-looking calls. Teams can investigate that behavior without first having to prove whether an attacker used AI.

API Security’s out-of-band analysis complements App & API Protector. Through their direct integration, API Security can trigger enforcement through App & API Protector for traffic on the protected path, according to the configured response. Separate integrations with security information and event management (SIEM) and IT service management (ITSM) tools support investigation, alerting, and case management.

Keeping session- and context-heavy analysis outside the request path avoids adding that processing to every request, while App & API Protector provides distributed inline enforcement. This architecture supports a performant and resilient protection strategy. Teams should validate the configured response, including detection-to-enforcement timing and the scope of traffic covered.

Where applicable, web application firewall (WAF) rules can provide virtual patching against exploit patterns while developers address the underlying defect. Blocking an abusive source does not repair a broken authorization check. Application-side access controls, permanent fixes, and validation remain essential.

An API inventory gives teams a baseline for improvement. Akamai’s posture and reporting capabilities help track findings and assess policy alignment over time. Testing results, incident records, and remediation evidence can show which risks have been addressed and where work remains to be done.

For the API portion of an action plan, we recommend documenting:

• Inventory coverage, connected discovery sources, and known visibility gaps

• Shadow and deprecated endpoints, assigned owners, and decisions to secure, restrict, or retire them

• Prioritized findings, sensitive-data exposure, remediation deadlines, and accepted exceptions

• Preproduction test coverage, failed checks, and retest results that validate fixes

• Runtime incidents, response actions, and measured detection-to-enforcement times

These are practical examples of API evidence for the bank’s broader resilience program. Banks should connect them to service criticality and risk tolerance, alongside incident response, recovery exercises, third-party assurance, and management accountability.

Eliminating shadow and zombie API exposure requires ongoing decisions about which services should exist, what they can access, and how they behave in production. Akamai API Security connects discovery, posture assessment, testing, and runtime analysis, while App & API Protector supplies complementary inline controls. Together, they help banks reduce API risk and document progress. Compliance remains the bank’s responsibility and depends on its overall controls and governance.

Read Akamai’s ECB Compliance Guide for a broader response, or explore Akamai API Security to see how discovery, testing, runtime detection, and integrated protection can support your bank’s API security program.