3.1.1 Architectural foundations

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.

1. Oversigt

1.1 Referencer

1.2 Identificerede krav

1.3 Relaterede reguleringer

2. Identificerede krav

3. Relaterede reguleringer

• ENISA -