Threat modelling a logistics partner API

The client is a Dutch logistics operator about to open a partner API to third parties. Once external partners are onboarded, the cost and difficulty of tightening the design rise sharply.

The threat surface that came with opening the network was poorly understood, and they wanted confidence before the first integration went live.

A new partner API would open the network to third parties, and the threat surface that came with it was poorly understood. Opening to partners meant opening to their compromise too.

Once external partners are onboarded, tightening the design is far harder: the time to get it right is before the first integration goes live. The window for cheap fixes was closing.

The operator needed confidence that abuse, replay, and authorisation flaws had been engineered out up front. Getting the design right before launch was the objective.

We threat-modelled the authentication and data flows in detail, focusing on how a malicious or compromised partner could abuse the interface. Assuming a hostile partner is what reveals the risks that matter for a partner API.

We identified abuse and replay risks and drove concrete mitigations into the design before any third party connected. Fixing them pre-launch is what avoids costly post-onboarding changes.

Authorisation boundaries were tightened so partners could reach only what they were entitled to, and the result was validated against the model to confirm no critical design risks remained at launch. The API opened to partners hardened.