People use these three words interchangeably and they should not, because the fix for each one is different.
A shadow API is undocumented and unmanaged — running without the knowledge of your IT and security teams. These are almost never malicious. Someone stood one up for a test or to solve a small problem under deadline, fully intending to catalog it later, and later never came. The intent was innocent; the result is an interface handling real traffic that nobody is monitoring, patching, or rate-limiting. That makes it the softest target you have, and attackers know it — one report put roughly 31% of malicious transactions against shadow APIs.
A rogue API is a step darker, and the distinction is worth keeping. A shadow API slipped through the cracks. A rogue API was deployed without authorization, deliberately outside your approved governance and security process. The difference is intent. If you have shadow APIs you have a documentation gap. If you have rogue APIs you have a controls gap — someone can ship to production while routing around every check you believed was mandatory — and that is a more serious conversation.
A zombie API is the ordinary one. It served a purpose, the team moved on, the consumers moved on, everyone assumed it went away — and it is still deployed, still reachable, still running the authentication and the unpatched code it had on the day it was abandoned. Zombies are dangerous precisely because they are frozen at the security posture of whenever everyone stopped looking, while the threat landscape kept moving. Deprecation without deletion is how you manufacture them, and most organizations are good at the first half of that sentence and bad at the second.
Underneath all three is one governance failure: a missing or incomplete registry. There is no authoritative list, so things fall off a list they were never on. You do not fix this by buying a scanner and running it once, though a scanner helps. You fix it by requiring that every API in production has a registry entry, an owner, a lifecycle status, and a defined end-of-life — and making that a condition of running in production rather than a nice-to-have. The registry is the spine. Discovery finds what is missing from it, ownership makes someone responsible for each entry, and lifecycle policy is what makes “deprecated” actually lead to “deleted” instead of to a zombie.
The raw count of APIs is not the problem. Ten thousand APIs you can see, name, and account for is a strength. Two hundred you cannot is a liability, and it is the two hundred that will hurt you.
