Trust boundary
A trust boundary marks where data or actions pass between parts of a system that have different trust assumptions, privileges, or control.
Look for a change in what can be trusted
A browser sends input to an application. An application asks a more privileged service to perform an operation. An organization accepts an assertion from an external identity provider. Each can involve a change in trust assumptions, even if no network firewall sits between the components.
Microsoft’s design guidance uses trust boundaries to separate areas with different levels of trust. OWASP recommends showing them alongside data flows, processes, and external entities in a threat model.
A line on a diagram does not enforce a restriction. It tells reviewers where to ask which checks are needed: who supplied the data, what may they request, and what must the receiving component verify before acting?
The help desk crosses a trust boundary too
A help-desk caller supplies information. An agent evaluates it, and an identity system may then change an authenticator or grant a recovery credential. The caller’s statement should not become an authorized account change merely because it entered a trusted ticketing system.
Recovery trust boundaries separates the specific changes hidden inside “restore access.” Federation trust changes examines a different boundary: which outside identity system can vouch for a user.
Once the boundary is mapped, a technical follow-on test can check whether the receiving system enforces the expected restriction.