Most organizations are exposing sensitive data through APIs without security controls in place, and they may not even realize it, according to Raidiam.

Their report, API Security at a Turning Point, draws on a detailed assessment of 68 organizations across industries. It deliberately excludes regulated environments like UK Open Banking, where advanced security is mandated. The goal was to understand how typical businesses, those without regulatory pressure, are protecting their APIs. The results aren’t encouraging.

Over 80% of organizations fell into what the report classifies as the “Act Urgently” category. These are companies that handle high-value personal or payment data through APIs but use weak controls such as static API keys, long-lived bearer tokens, or basic OAuth with shared secrets. Only one organization in the entire sample had deployed what researchers consider a modern security stack for APIs, relying on client certificate authentication, sender-constrained tokens, and mutual TLS (mTLS).

This gap between data sensitivity and security posture is the core problem the researchers want to expose. “Most organizations are behind the curve on API security hardening, even as their reliance on APIs has grown,” the report warns.

A fragile foundation

The widespread use of APIs to support mobile apps, cloud services, and partner integrations means that the attack surface has changed. But the security practices often haven’t. APIs today handle everything from identity claims and cardholder data to health and account information. Yet in many organizations, they remain outside the scope of standard security programs.

The report points out that only 27% of organizations have visibility into what sensitive data is exposed via their APIs. Less than half conduct API-specific security testing such as fuzzing or dynamic analysis. Monitoring is also lacking, meaning attackers may probe or misuse APIs for weeks without detection.

What better looks like

Raidiam lays out a path to stronger API security, and most of it comes down to adopting practices already proven in regulated spaces. Financial-grade APIs, for instance, rely on mutual TLS to authenticate both client and server, making it much harder for attackers to impersonate legitimate apps. They also use certificate-bound tokens, which prevent token theft from becoming a valid access method.

These are not theoretical improvements. Open Banking regimes in the UK, Europe, and Australia mandate such controls, and every bank in the UK has implemented them. But in industries without regulatory pressure, adoption remains low.

This creates a two-speed environment: one group of organizations treats APIs as core business infrastructure with security governance, while the other group treats them as just another developer tool.

“Whilst most organizations surveyed in the report lag behind on API security, those that have moved ahead, such as banks required to by regulation, or global card schemes who’ve acted voluntarily, dwarf the laggards in scale and maturity,” David Oppenheim, Head of Enterprise Strategy at Raidiam, told Help Net Security. “This creates a stark contrast in risk posture.”

Oppenheim added that meaningful oversight at the board level doesn’t require technical fluency. “Board-level metrics in such a technically complex space can be difficult to surface meaningfully, but there are still effective ways to guide oversight and investment. Directors should ask which recognised standards (e.g. FAPI) have been adopted or are in the roadmap, and whether the organization has applied a maturity model or framework to benchmark its current posture and track improvements over time.”

He also mentioned an easy place to start.: “A simple but powerful KPI might be the percentage of API integrations still relying on static keys or shared secrets, paired with a timeline to migrate toward cryptographic protections. Tracking reduction over time gives non-technical visibility into security improvement.”

Structural change may be coming

So far, the biggest improvements in API security have come either through direct regulation or industry-led mandates. But pressure is building elsewhere.

“Again, organizational size plays a key role,” said Oppenheim. “Larger firms and infrastructure providers are already moving ahead voluntarily – not just in banking, but in payments and identity platforms – because they see strong API security as a necessary foundation for scale and trust.”

He added that compliance tailwinds are emerging: “Changes to TLS Baseline Requirements will impact all organizations with a digital footprint, while regulations like DORA are driving new expectations around third-party risk – especially relevant for APIs exposed to external partners.”

Oppenheim also sees broader architecture trends helping move things forward. “The NIST Zero Trust Framework is beginning to serve as a blueprint for many organizations seeking to reduce implicit trust across their digital environments. In that context, strong client identity through PKI or mutual TLS is part of a broader move toward defensible, verifiable architectures.”

Share.

Comments are closed.