Every door has a lock and an owner: governing third-party access for a Japanese online securities firm

The situation

A Japanese online securities firm ran its trading and account platforms on AWS. Over the years it had connected a long list of suppliers: a data platform that read market and customer data through a cross-account role, an observability vendor with read access to logs and metrics, a managed service provider that ran remote management agents on office devices, and SaaS tools connected to the firm's email and file storage through OAuth grants. Each connection had been approved by the team that needed it, at the time it was needed. Nobody had a complete list.

The FSA's cybersecurity guidelines for the financial sector, in effect since October 2024, treat third-party risk management as a core area, including outsourcing and cloud services⁵. The firm's supplier assessments were thorough on paper: questionnaires, certifications and contract clauses. What they did not show was what each supplier could technically do inside the firm's systems today.

Why now. In early November 2026, Wiz reported that an attacker had used credentials tied to Qubole's AWS account to assume integration roles that customers had created to trust Qubole, then collected secrets and data from those customers' accounts¹. Days later, N-able took its hosted N-central remote management platform offline after a researcher published alleged zero-days². Both showed the same thing: a supplier's access is only as safe as the supplier.

What had to be true

• Known: every supplier's technical access in one ledger.
• Owned: an internal owner and a business reason for each.
• Narrow: each supplier can do only what its service needs.
• Watched: unusual supplier activity raises an alert.
• Revocable: any supplier's access can be cut quickly, without guesswork.
• Evidenced: supervisors and auditors can see all of the above.

Architecture

Every cross-account role was rebuilt following AWS's guidance for third-party access: a trust policy naming the vendor's account, a unique external ID for the relationship and permissions limited to the specific actions and resources the service needed³⁴. Service control policies set limits no supplier role could exceed, such as never reading the secrets manager or changing identity settings. Where a vendor could commit to fixed source networks, resource policies only accepted vendor access from those networks. The model is the one Kubernetes teaches for role-based access: a narrowly defined role, bound explicitly to named identities⁶.

The data flow, end to end

The hard part: when the supplier itself is compromised

External IDs are not enough. An external ID protects against the confused deputy problem, where one customer tricks a vendor into acting on someone else's account³. It does not help when the vendor's own systems are compromised; in the Qubole case, the attacker's requests were accepted by customers' roles¹. So the firm assumed every supplier could one day be the attacker, and designed so that a compromised supplier could reach only a narrow slice of data, could not read secrets and would trigger alerts by behaving differently.

Detecting "normal but wrong". A compromised supplier uses valid credentials, so authentication alerts stay quiet. The firm built a simple baseline per supplier: usual source networks, usual hours, usual API actions and usual data volumes. Departures from that baseline, such as a new network, listing every bucket or reading parameters it had never read, raised alerts to the security team and the supplier's internal owner.

Remote management tools. The managed service provider's agents could run commands on every office device, so they received the strictest treatment: access only to office devices, never to trading systems; just-in-time sessions approved per task; and a tested way to stop the agents across the fleet if the provider was compromised. See the MSP cyber resilience case study.

How it ran

Key decisions and trade-offs

What I'd do again, and differently

Again: start with the inventory of roles trusting outside accounts. It found integrations for services the firm had stopped using years earlier, still active. Differently: involve procurement from the start, so new suppliers are onboarded into the ledger rather than discovered later. Related: the 10 November tech news, the machine and agent identity case study, securing MCP servers and where I work.

If you cannot list every supplier that can reach your cloud, or cut one off quickly, see my fractional CTO work, or analyse your challenge and bring the result to a call.