Security teams cannot protect APIs they do not know exist. Rogue APIs introduced by business units without security review and zombie APIs left running after projects are abandoned are expanding the attack surface inside environments that operators believe are fully inventoried. The gap between what security teams think they own and what is actually live in production is where breaches begin.
In this interview on TFiR, Steve Winterfeld, Advisory CISO at Akamai, walks through the API visibility problem, the operational patterns that create rogue and zombie APIs, and how adaptive security controls allow organizations to tune fraud tolerance and customer friction dynamically.
Guest: Steve Winterfeld, Advisory CISO at Akamai
Show: TFiR
Here is what every security engineer, platform team, and CISO needs to know.
Technical Deep Dive
Q: Why is API sprawl still a major security problem even in mature organizations?
Steve Winterfeld, Advisory CISO at Akamai, explains that the core issue is not technical complexity but organizational behavior. Business units add APIs to production environments to support analytics, campaigns, or experiments without routing them through security review. The result is a growing population of APIs that exist inside the operational environment but outside the security envelope, with no inventory entry and no monitoring.
“Marketing just came in and added a new capability for analytics. And now I have a new API in my operational environment that may or may not be under my security envelope.” — Steve Winterfeld, Advisory CISO, Akamai
Q: What is a zombie API and why is it a security risk?
Winterfeld defines a zombie API as one that was created to support a specific business operation or experiment, then left running after that operation ended. Because the project it supported is closed, the API receives no maintenance, no security patches, and no monitoring. It remains accessible from the outside but is invisible to the team responsible for securing it.
“Somebody set up an API, did an experiment, ran a business operation, stopped that operation, never took down the API. So now it’s not being maintained, it’s not being updated.” — Steve Winterfeld, Advisory CISO, Akamai
Q: What is the first step in any API security program?
Winterfeld is direct on this point: discovery must come before any protection strategy. Organizations consistently overestimate how complete their API inventory is. When Akamai deploys its capabilities, the discovery phase routinely surfaces APIs that the customer’s own operations and security teams had no record of. You cannot define a protection scope or apply controls to assets you have not found.
“I don’t know of any case where we went in and didn’t find things that the company didn’t know about.” — Steve Winterfeld, Advisory CISO, Akamai
Q: How should security teams frame API risk for board-level conversations?
Winterfeld frames board conversations around risk appetite rather than technical controls. Boards make trade-off decisions: they may accept a higher fraud rate to remove friction during a major sales event, or accept more friction to drive fraud down. Security teams need to present API controls in terms the board can act on, specifically what level of fraud or friction the organization is willing to tolerate under different business conditions.
“They may accept more fraud for a dramatic increase in sales. They may accept more friction between the customer and the company to dramatically reduce fraud.” — Steve Winterfeld, Advisory CISO, Akamai
Q: What does adaptive API security control mean in practice?
Adaptive control means the security team can increase or decrease the intensity of API protections in response to changing conditions without a full deployment cycle. Winterfeld describes scenarios where controls tighten as fraud increases, and loosen during high-traffic sales events to reduce customer friction. The architecture has to support that kind of dynamic adjustment, not just static rule sets applied at deployment time.
“I need security controls where I can adaptively meet that requirement and adapt as the fraud gets worse. I can increase controls.” — Steve Winterfeld, Advisory CISO, Akamai
Resources & Documentation
- Akamai API Security, Akamai’s API discovery and protection platform referenced throughout this discussion
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: Now let’s talk about the API. How, I mean, we have been talking about APIs for so long, the patterns remain same or something different is happening because we kind of live in API driven world.
Steve Winterfeld: So I think APIs, one of the biggest concerns is do I know where they are. I spend a lot of time thinking about rogue APIs. You know, marketing just came in and added a new capability for analytics. And now I have a new API in my operational environment that may or may not be under my security envelope. I have zombie APIs. Somebody set up an API, did an experiment, ran a business operation, stopped that operation, never took down the API. So now it’s not being maintained, it’s not being updated. You know, so all of these different kinds of APIs out there and just people doing their business and not using the security guardrails, not following policies. And so the proliferation of APIs is dramatic. And so the first thing I need to do is discovery. You know, again, when API goes out and works with customers, that’s often the first phase is we, when we put in our capabilities, a huge part of that is discovery. And I don’t know of any case where we went in and didn’t find things that the operation, the company didn’t know about. And so the first part is do you know what you need to protect? The second part is how do you want to protect that? So again, when I talk to the board, they want a risk appetite view of the world. They may accept more fraud for a dramatic increase in sales. They may accept more friction between the customer and the company to dramatically reduce fraud. And so I need security controls where I can adaptively meet that requirement and adapt as the fraud gets worse. I can increase controls. As we have a major sale and I want to, I want to get rid of all the friction during the major sale, then I can do those kind of things. So a lot of for me is that dynamic ability to control the mitigation around the APIs and knowing where they are.





