Topic starter
02/08/2026 12:17 pm
TL;DR: 91% of respondents reported a security incident in the last 12 months, Salt Security found, while malicious traffic rose 211% against 51% API growth. API monitoring now has to judge live behaviour, identity scope, and data sensitivity to separate normal use from abuse.
Editorial analysis by NHI Mgmt Group, based on content published by Salt: “Lessons from the FinTech Trenches Securing APIs at Finastra”.
By the numbers:
- 91% of those surveyed experienced a security incident in the last 12 months.
- API traffic for Salt customers has grown 51% while malicious traffic has grown at 211%.
- Malicious traffic has grown at 211%.
Key questions
Q: Why does API traffic growth increase abuse risk?
A: When API usage grows, defenders get more legitimate noise to separate from malicious behaviour.
Q: What are the signs that API security monitoring is failing?
A: API monitoring is failing when teams cannot see request patterns, access failures, or unusual traffic in real time.
Q: Where do gateway controls fail in API security programmes?
A: Gateway controls fail when they are treated as the whole control plane.
Practitioner guidance
- Map API traffic to runtime context Correlate caller identity, endpoint sequence, data touched, and business workflow so abuse can be separated from legitimate variation.
- Classify APIs by data sensitivity Identify which APIs expose regulated or operationally sensitive data and prioritise deeper monitoring on those services first.
- Integrate security into CI/CD and runtime workflows Connect API discovery and design review to live detection and response so development and security teams work from the same inventory.
Bottom line: API security now depends on understanding runtime behaviour, not only on filtering traffic at the gateway.
Glossary terms: Runtime Context, API Behavioural Monitoring, Non-Human Identity (NHI), API Data Exposure
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
02/08/2026 1:19 pm
API security has become a runtime governance problem, not just an edge-control problem. Gateways and WAFs can still filter traffic, but they do not provide enough context to judge intent, sequence, or data sensitivity. That gap matters most where APIs sit in the core of financial and partner ecosystems. Practitioners should treat runtime correlation as part of API governance, not an optional monitoring layer.
A few things that frame the scale:
- Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
- 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
A question worth separating out:
Q: How should IAM teams govern API access patterns that are designed for developers first?
A: Treat developer-facing API patterns as identity design decisions, not just application plumbing. Review authentication method, token scope, revocation path, and logging at the point the pattern is introduced, because those choices often become inherited control assumptions once the system is in production.
👉 Read our full editorial: API security now depends on runtime context, not just gateway controls