3.1 Secure by design principles

Architectural foundations are the blueprints for a system’s security; they focus on the structural design choices that make a product inherently difficult to compromise or exploit. This category establishes the fundamental rules for how data flows, how components interact, and how the system contains a potential breach before it can spread.

The following principles fall under this category.

• Trust boundaries and threat modelling. These concepts reflect two related security principles: trust should be made explicit rather than assumed, and threats should be identified before and throughout development. Trust boundaries define where data, identities and execution contexts cross from a more trusted domain to a less trusted one (or vice versa), such as between a device and a cloud service, a user and an admin interface or one microservice and another. Boundaries clearly identify which components must authenticate each other, where input must be treated as untrusted and where additional controls (e.g. validation, rate limiting, encryption or isolation) are required. Threat modelling also provides a structured way to identify what could go wrong at these boundaries by mapping key assets (e.g. credentials, firmware images, customer data), likely threat actors and realistic attacker capabilities and assumptions.
• Least privilege. Systems and users should be granted only the feasible minimum level of access required to perform their functions. Restricting permissions reduces the impact and limits the scope of compromise. Least privilege should be applied consistently across user accounts, service accounts, APIs and administrative roles, and privileges should be elevated only when needed and for the shortest feasible duration.
• Strong identity and authentication architecture. A secure product architecture requires a clear and consistent approach for how identities are created, verified, and managed for users, devices, services, and administrators. This includes defining authoritative identity sources, establishing how authentication occurs across interfaces (e.g. web portals, APIs, local management consoles and device-to-cloud communication) and ensuring that authentication is resistant to common attacks such as credential stuffing, replay attacks and session hijacking.
• Attack surface minimisation. Unnecessary features, services and interfaces increase the number of potential attack vectors. Therefore, reducing system complexity and disabling unused or unnecessary components reduces the likelihood of vulnerabilities being introduced or exploited. This includes removing default accounts, uninstalling unused packages, closing non-essential ports, removing unused code and limiting exposed management interfaces to trusted networks only. Standardised secure baselines and hardened configuration templates make it easier to keep systems consistently minimal as they scale. Ongoing vulnerability scanning and asset inventory are also important, because you cannot minimise what you do not know exists.
• Defence in depth. Applying layered security controls ensures that the failure of a single mechanism does not result in complete compromise. Layers can include preventive controls (e.g. multi-factor authentication (MFA), network segmentation), detective controls (e.g. monitoring, logging, anomaly detection) and corrective controls (e.g. automated isolation, backup/restore). Effective defence in depth also assumes that some controls will be bypassed, so systems should be designed to degrade gracefully and still protect critical assets. This approach reduces reliance on any single silver bullet and increases the attacker’s cost and time to achieve their objectives. It is strongest when controls are diverse (not all dependent on the same technology or trust assumption).
• Open design (avoiding obscurity). Systems should not depend on secrecy of design or hidden behaviour for protection. Security controls should remain effective even if an adversary understands how the system operates. This principle encourages the use of well-studied algorithms and protocols, clear documentation and designs that can withstand scrutiny through review and testing. Open design does not mean making secrets public; rather, it means that the security of the product should rest on protected keys, strong authentication and robust implementation, not on keeping the mechanism itself hidden. In practice, it also supports maintainability, because transparent designs are easier to audit, validate and improve over time.

Operational integrity addresses the human and procedural practices that maintain product security throughout development, deployment, operation and retirement. It ensures that security is treated as a continuous, lived experience, for developers and users alike, rather than a one-time checklist completed during the design phase.

This category includes the following principles.

• Life-cycle management. Security responsibilities extend beyond initial development. Components must be maintained, updated and eventually retired in a controlled manner, taking the expected duration of use into account. The practical application of life-cycle management, including how secure by design and secure by default principles are applied from design and development through to decommissioning, is explored in Section 2.
• User-centric design. Security mechanisms must be usable and understandable even for everyday users. Poor usability often leads to insecure workarounds or misconfigurations. For example, if a system requires the user to perform complex manual configuration to enable encryption, they may skip the step or apply it incorrectly. On the other hand, providing a simple, guided set-up that enables encryption automatically reduces the chance of misconfiguration and encourages the use of the security feature.
• Secure coding and verification practices. Developers should follow established secure coding standards to prevent common vulnerabilities. Early identification and mitigation of insecure code ensure that weaknesses are not built into the system. For example, developers can use SAST tools (18) while coding to identify vulnerabilities and software composition analysis to detect vulnerable third-party libraries. They can then apply dynamic testing tools (19) (DAST) before deployment to uncover runtime issues. These practices ensure that code-related vulnerabilities are identified early and not after the product is released.
• Logging, monitoring and alerting. Security depends on visibility. Systems should generate appropriate security-relevant logs, retain them for a defined period and protect them from tampering, so that they can support investigation and compliance needs. Rather than simply collecting data, monitoring should be designed to detect suspicious behaviours such as repeated failed authentication attempts, privilege escalation, unexpected configuration changes and unusual outbound connections.
• Configuration and change management. Secure operation requires configurations to be controlled, consistent and auditable. Baseline hardening standards should be defined (e.g. secure defaults, disabled unused services and enforced encryption settings) and applied through repeatable mechanisms such as templates and infrastructure as code to reduce drift. Changes to systems should follow a governed process that includes review, testing, approval and rollback plans, particularly for security-sensitive components.
• Incident response and recovery. Developers must be prepared to respond quickly and effectively to security incidents that affect their products in the field, including vulnerabilities, compromised code, malicious updates and misuse of product functionality. This requires defined internal roles, escalation paths and decision-making authority for security events, as well as documented playbooks for containment and customer communication.
• Vulnerability and patch management. Vulnerability and patch management should be practical, repeatable and prioritised by risk. Manufacturers need a simple way for customers and researchers to report issues (e.g. a dedicated security email address and a basic disclosure process) and an internal process to triage findings quickly and decide what needs urgent action.
• Supply-chain controls. Developers and manufacturers should protect product integrity without excessive process overhead, focusing on the points where a compromise would have the largest impact: code repositories, build systems, signing keys and the channels used to distribute updates. At a minimum, source code and CI/CD modification rights should be limited to named individuals, protected with MFA and reviewed through lightweight peer approval for changes to security-critical areas. Software bills of materials (SBOMs) should be generated and maintained to support dependency transparency, vulnerability management and product life-cycle security.