Notifications
Clear all
Topic starter
02/08/2026 12:14 pm
TL;DR: Tariffs and related trade disruptions are forcing rapid vendor swaps, regionalisation, and workflow rewiring that expand API attack surfaces, create shadow and zombie endpoints, and weaken governance, according to Salt. The security issue is not the tariff itself but the rushed operational change it triggers, where old trust assumptions persist after systems move.
NHIMG editorial — based on content published by Salt: Tariffs and global trade: what security teams need to know about APIs
Questions worth separating out
Q: What breaks when API changes are rushed during vendor or regional transitions?
A: The usual failure is not the new API itself but the old trust model that survives beside it.
Q: Why do shadow and zombie APIs increase security risk so quickly?
A: They extend machine-to-machine trust beyond the inventory and ownership controls that normally constrain access.
Q: What do security teams get wrong about API-based integration?
A: They often treat APIs as a technical convenience instead of an access boundary.
Practitioner guidance
- Inventory every exposed and deprecated API after business reroutes Reconcile API inventories whenever tariffs, sanctions, or vendor swaps force a change in data flow.
- Block insecure fallback behaviour in client applications Review retry logic, fallback authentication, and default-mode handling so degraded upstream services cannot disable validation or weaken access checks.
- Bind every API to an accountable owner and retirement date Assign ownership, business purpose, and revocation criteria to each API and service integration.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- Specific examples of how tariff-driven vendor changes can leave deprecated APIs live after migration
- Operational guidance on spotting shadow APIs, zombie APIs, and hidden partner dependencies in production
- Practical monitoring approaches for broken integrations, fallback modes, and traffic anomalies
- Security funding and governance arguments a CISO can use when API risk is being under-resourced
👉 Read Salt's analysis of how trade disruption expands API security risk →
Tariff-driven API sprawl: what security teams need to watch?
Explore further
02/08/2026 1:17 pm
API security is becoming a supply chain identity problem, not just an application problem. When business disruption forces rapid reconfiguration, the real failure is often uncontrolled machine-to-machine trust across vendors, regions, and fallback systems. That pattern mirrors NHI sprawl in other environments, where credentials persist after the original workflow has changed. Practitioners should treat every API change as an identity lifecycle event, not just a deployment task.
A question worth separating out:
Q: Who is accountable when deprecated APIs remain live after a business change?
A: Accountability should sit with the service owner, the platform team that approved the change, and the security function that sets lifecycle policy. If no one can state when the endpoint was retired, who approved its continued reachability, and how access was revoked, the governance model has failed.
👉 Read our full editorial: Trade disruption is widening API risk across modern supply chains
