Trust is an engineering property before it is a business property. This sounds abstract, but it has specific practical implications for how enterprises should design the systems that connect them to customers, partners, suppliers, and their own workforce. The phrase "trust by design" is the security equivalent of "privacy by design" — the principle embedded in GDPR Article 25 that data protection obligations should be addressed in the technical architecture from the beginning, not bolted on through configuration and policy after deployment. Applied to trust broadly, it means that the mechanisms by which your systems verify identity, authenticate actions, enforce access boundaries, and audit behaviour should be designed into the architecture of every connected system from the first infrastructure decision, not added as a security layer after the product has been built.
The connected enterprise in 2026 has a trust surface that is categorically different from even a decade ago. The trust relationships an enterprise must manage now include: employees accessing corporate resources from personal devices on unmanaged networks; machine identities — service accounts, API keys, cloud workload identities, CI/CD pipeline credentials — that now numerically dominate enterprise identity estates; third-party software supply chain relationships where a compromise upstream can propagate into the enterprise through trusted software update mechanisms; AI agents acting on behalf of users with delegated but semantically opaque authorisations; and partner integrations where B2B API access must be continuously authorised against a dynamic set of business conditions. None of these relationship categories was prominent in the threat model of a 2010-era enterprise. All of them require architectural responses that go beyond perimeter security and credential management.
The first principle of trust by design that we think about most often is: make trust explicit. Implicit trust — the assumption that a component operating inside a defined network boundary or holding a valid credential can be trusted to behave within its authorised scope — is the root cause of most significant breach narratives of the past ten years. Supply chain compromises work because build systems and software update mechanisms are trusted implicitly: they are authorised to install software, and the content of that software is not subject to additional verification. Insider threat scenarios work because users with legitimate credentials and network access can reach resources that are not in their operational scope without any system challenging the access. Making trust explicit means encoding the specific conditions under which trust is granted — and continuously verifying that those conditions are still met — rather than granting trust based on a one-time authentication event and relying on policy to prevent misuse.
The second principle is proportionality: match the strength and persistence of a trust assertion to the risk profile of the action being authorised. FIDO2/WebAuthn authentication provides strong cryptographic proof of control over a registered device and authenticator, with phishing resistance properties that password-based authentication cannot match. For an enterprise user accessing email, password-plus-SMS MFA is adequate — the risk of email access compromise is meaningful but bounded. For the same user promoting a container image to a production registry, or approving a financial transaction above a defined threshold, or accessing a database table containing personal health information, a fresh strong authentication assertion is warranted. Step-up authentication — requiring progressively stronger verification for progressively higher-risk actions within a session — is the technical mechanism, and it requires both the IdP to support it and the application to request it. Most enterprise applications still do not request step-up authentication for high-risk operations within an established session, which is a design gap rather than a technology gap.
The third principle is auditability as a first-class requirement. Trust decisions — who was granted access to what, under what conditions, based on what signals — must be auditable not just for compliance purposes but for incident response. When a compromise is discovered, the investigation's first requirement is reconstructing the access chain: what identity performed which actions, through which systems, with which authorisations, at what times. Organisations that have designed this auditability into their systems from the beginning — with structured access logs, immutable audit trails, and the data retention policies to support reconstruction months after the fact — have forensic capability that organisations with ad-hoc logging do not. NIS2's incident reporting requirements and DORA's ICT incident management obligations are both creating regulatory mandates for this kind of structured auditability that will force it into regulated sector design requirements whether or not organisations adopt it voluntarily. The architecture decisions required to build auditable systems are significantly cheaper to make at design time than to retrofit into a running production environment.