Fact-checked by Grok 2 weeks ago

Secure by Design

Secure by Design is a cybersecurity principle and approach that emphasizes integrating security into the fundamental architecture and development of technology products from the outset, rather than treating it as an add-on or retrofit measure, to proactively mitigate risks from malicious actors and prevalent threats.^[1] This methodology shifts the burden of security from end-users to manufacturers, promoting practices such as threat modeling, use of memory-safe programming languages, and defense-in-depth strategies to build resilient systems that protect devices, data, and infrastructure by default.^[1] Key tenets include radical transparency in vulnerability disclosure, organizational accountability through dedicated security leadership, and eliminating insecure defaults like generic passwords or unpatched configurations, ensuring products are secure out-of-the-box with minimal user intervention required.^[1] Initiated prominently by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) in collaboration with international partners like the UK's National Cyber Security Centre and Australia's ACSC, the Secure by Design framework was formalized in an April 2023 whitepaper outlining three core principles: placing the burden of security on manufacturers rather than customers, radical transparency and accountability, and shaping organizational culture and incentives to prioritize security goals.^[1] Complementing this, the related Secure by Default concept calls for products to ship with secure baselines, such as multi-factor authentication (MFA) for privileged users (opt-out by default) and single sign-on (SSO), while prioritizing security over backward compatibility to reduce exploitable weaknesses.^[1] Organizations like the Open Web Application Security Project (OWASP) extend these ideas through frameworks such as the Secure Product Design Cheat Sheet and Secure-by-Design Framework, which provide tactical guidance for architects, including principles like least privilege, zero trust, and security-in-the-open to minimize attack surfaces during the design phase of the software development lifecycle (SDLC).^[2]^[3] Notable implementations include CISA's Secure by Design Pledge, launched on May 8, 2024, to encourage software vendors to adopt these practices, with over 20 initial signatories (including Microsoft and Google) committing to tactics like software bills of materials (SBOMs) for transparency and automated security testing tools such as static application security testing (SAST); as of 2025, companies continue to submit progress reports on these commitments.^[4]^[5] These efforts, including CISA's 2024 Secure by Design Alerts series and an updated joint guidance document, address systemic vulnerabilities by advocating for memory-safe languages (e.g., Rust or Java) to prevent common exploits like buffer overflows, which account for a significant portion of cyberattacks.^[1] Overall, Secure by Design represents a paradigm shift toward proactive, manufacturer-led security, influencing standards from NIST's Secure Software Development Framework (SSDF) version 1.1 to global regulatory expectations, ultimately aiming to create a more secure technology ecosystem.^[6]

Overview

Definition and Importance

Secure by design is a foundational approach in software, hardware, and system development that integrates security as a core requirement from the initial design phase, rather than retrofitting it later. This philosophy emphasizes proactively addressing potential threats to prioritize customer protection and minimize exploitable vulnerabilities throughout the product lifecycle. According to the Cybersecurity and Infrastructure Security Agency (CISA), secure by design means "technology products are built in a way that reasonably protects against malicious cyber actors successfully gaining access to devices, data, and connected infrastructure," incorporating risk assessments and layered defenses from the outset.^[1]^[7] The importance of secure by design lies in its ability to shift cybersecurity responsibility toward manufacturers, reducing the burden on end-users and preventing widespread breaches that disrupt critical infrastructure. By embedding security early, organizations avoid the high costs associated with reactive patching and incident response, as unpatched vulnerabilities in poorly designed products often enable attackers to exploit systemic weaknesses. For instance, CISA highlights how such flaws have led to real-world impacts, including hospitals canceling surgeries due to ransomware enabled by insecure technology. This contrasts sharply with "security by obscurity," which relies on hiding implementation details rather than building inherent resilience, often failing against determined adversaries.^[1]^[7] Key benefits include enhanced resistance to attacks through principles like least privilege, which limits access to essential functions only, thereby reducing the potential impact of any single breach. Secure by design also accelerates time-to-market for reliable products by streamlining development and minimizing post-release fixes, while fostering compliance with emerging regulations such as the EU Cyber Resilience Act. Furthermore, it aligns with broader business objectives, as evidenced by CISA's 2024 Secure by Design Pledge, where as of November 2025 over 340 vendors, including Microsoft and Google, have committed to embedding security into their product roadmaps and transparently addressing known defects. This collective effort builds trust and promotes industry-wide resilience against evolving threats.^[1]^[4]^[8]

Historical Development

The concept of secure by design originated in 1975 with the seminal paper "The Protection of Information in Computer Systems" by Jerome H. Saltzer and Michael D. Schroeder, which introduced eight foundational protection principles aimed at safeguarding computer-stored information from unauthorized access or modification.^[9] These principles emphasized mechanisms like complete mediation and least privilege to ensure robust system protection from the outset. In the 1980s and 1990s, these ideas gained traction through their integration into operating system architectures and security standards. Unix and its variants incorporated elements such as discretionary access controls and fail-safe defaults, drawing from earlier influences like Multics to enhance protection in multi-user environments.^[10] Concurrently, the Bell-LaPadula model, developed in the mid-1970s but widely adopted in military and government systems during this period, formalized confidentiality protections through mandatory access controls, influencing certified secure operating systems under the Trusted Computer System Evaluation Criteria (TCSEC).^[11] The 2000s marked a resurgence of secure by design in software development practices amid growing internet vulnerabilities. The Open Web Application Security Project (OWASP) was founded in 2001 to promote secure coding and application security, providing resources that embedded design principles into web development. In 2004, Microsoft introduced the Security Development Lifecycle (SDL), a structured process integrating security requirements, threat modeling, and testing from the initial design phase to reduce vulnerabilities in software products.^[12] Recent developments have accelerated adoption through policy and industry commitments. Executive Order 14028, issued in 2021, mandated federal agencies to adopt secure software development practices and strengthen supply chain security, responding to high-profile incidents like SolarWinds. In 2023, the Cybersecurity and Infrastructure Security Agency (CISA) launched the Secure by Design initiative, issuing joint guidance with agencies like the National Security Agency (NSA) and the UK's National Cyber Security Centre (NCSC) to urge software manufacturers to prioritize security in product design and default configurations.^[4] The pledge launched in May 2024 with 68 initial signatories, including Ivanti and SolarWinds, growing to over 250 by the end of the year and exceeding 340 as of November 2025.^[8]^[13] By 2025, progress continued with Microsoft's Secure Future Initiative (SFI) releasing its April progress report, detailing advancements across 28 objectives such as zero-trust architectures and identity protections; meanwhile, the EU Cyber Resilience Act entered into force in December 2024, setting mandatory cybersecurity requirements for digital products with enforcement of core obligations beginning in December 2027.^[14]^[15]

Core Principles

Least Privilege and Separation of Duties

The principle of least privilege dictates that users, processes, or systems should operate with the minimal set of permissions required to perform their intended functions, thereby limiting the potential damage from errors, accidents, or compromises. This approach reduces the scope of possible misuse and facilitates auditing by confining investigations to a narrower range of activities. For instance, in database management, query analysts might be granted read-only access to specific tables, preventing unintended modifications or deletions even if their credentials are compromised.^[16] Complementing least privilege, the principle of separation of duties—also termed separation of privilege—requires that critical operations involve multiple distinct conditions or parties to authorize access, avoiding reliance on a single point of control that could be exploited. This enhances robustness by distributing trust across entities, such as requiring separate keys or approvals, which makes it more difficult for a single failure or malicious actor to enable unauthorized actions. In financial systems, for example, one role may authorize transactions while another executes them, mitigating risks of fraud or insider threats by ensuring no individual can complete a sensitive process independently. These principles are commonly implemented through role-based access control (RBAC) models, where permissions are assigned to roles rather than individuals, aligning access with organizational functions and enforcing both least privilege and separation of duties.^[17] The NIST RBAC standard supports hierarchical and constrained variants to further refine role inheritance and mutual exclusions, promoting scalable enforcement in complex environments. In practice, applying these principles limits lateral movement during breaches; for example, in the 2020 SolarWinds supply chain attack, attackers exploited overly permissive domain administrator accounts to traverse networks, a scenario that stricter adherence to least privilege could have contained by restricting initial footholds.^[18] Such integration into the secure software development lifecycle ensures these controls are embedded from design through deployment.^[17]

Economy of Mechanism and Minimize Attack Surface

The principle of economy of mechanism emphasizes designing security mechanisms to be as simple and small as possible, thereby reducing the likelihood of implementation errors and facilitating thorough verification. This approach, articulated by Jerome Saltzer and Michael Schroeder, argues that complexity in security components invites subtle flaws that can be exploited, whereas simplicity allows for easier auditing and maintenance. For instance, developers should prefer established, straightforward authentication protocols like OAuth 2.0 over custom cryptographic solutions, as the latter often introduce unintended vulnerabilities due to the challenges of correctly implementing cryptographic primitives without expert oversight. Minimizing the attack surface complements this by systematically eliminating unnecessary features, open ports, code paths, or services that could serve as entry points for adversaries, thereby reducing the overall opportunities for exploitation. Organizations can achieve this through practices such as disabling unused services on servers, which prevents potential attackers from leveraging dormant components that may harbor unpatched vulnerabilities.^[19] Tools like Microsoft's Attack Surface Analyzer assist in quantifying these risks by scanning systems for changes in exposure—such as new registry keys, services, or network bindings—introduced by software installations, enabling developers to iteratively shrink the surface area.^[20] In modern architectures, modular design in microservices architectures exemplifies both principles by isolating components into small, focused units, where each service exposes only essential interfaces, thereby limiting the blast radius of any compromise. This modularity aligns with an extension of Kerckhoffs' principle from cryptography—originally stating that a system's security should rely solely on the secrecy of the key, not its design—to software engineering, ensuring that non-secret elements remain simple and verifiable without relying on obscurity.^[21]

Open Design and Avoid Security by Obscurity

The open design principle posits that the security of a system should depend solely on the secrecy of its keys or other confidential elements, rather than on the obscurity of its design or implementation details. This foundational concept, articulated by Dutch cryptographer Auguste Kerckhoffs in his 1883 publication La Cryptographie Militaire, asserts that a cryptosystem remains secure even if all aspects except the key are publicly known, allowing for rigorous evaluation by experts to identify and mitigate weaknesses.^[22] By promoting transparency in design, open design enables widespread peer review, which strengthens security through collective scrutiny rather than relying on hidden mechanisms that could harbor undetected flaws. In contrast, security by obscurity—where protection is assumed from concealing implementation details—fails to provide robust defense and often invites exploitation once secrets are revealed. Proprietary algorithms, for instance, lack the broad analysis afforded to open standards, making them vulnerable to undetected vulnerabilities; historical cases demonstrate that such approaches collapse rapidly under targeted reverse engineering. A prominent example is the Content Scrambling System (CSS) used for DVD copy protection, introduced in 1996 without public specification; in 1999, Norwegian programmer Jon Johansen reverse-engineered and released DeCSS, a decryption tool, exposing CSS's weak 40-bit keys and flawed design, which rendered the system ineffective despite its intended secrecy.^[23] This incident underscored how obscurity not only delays but ultimately accelerates breaches by discouraging proactive audits. The Advanced Encryption Standard (AES), selected by the National Institute of Standards and Technology (NIST) in 2001 through a public competition, exemplifies successful open design. AES, specified in Federal Information Processing Standards (FIPS) 197 as a symmetric block cipher with 128-, 192-, or 256-bit keys, underwent extensive global review during its development, ensuring its resilience against known attacks and establishing it as a cornerstone for secure data protection in applications worldwide.^[24] Unlike proprietary alternatives, AES's openness has facilitated ongoing cryptanalysis, confirming its strength without compromising confidentiality when paired with secure key management. Open design yields significant benefits through community-driven improvements, particularly in open-source software where peer review uncovers vulnerabilities that closed systems might overlook. The Linux kernel, maintained under the Linux Foundation, leverages thousands of contributors for code audits, enabling rapid identification and patching of security issues; this transparency has contributed to its robustness in enterprise and critical infrastructure environments.^[25] Complementing this, simplicity in mechanisms aids openness by making designs easier to scrutinize publicly. Government guidance further reinforces these practices, emphasizing transparency to enhance overall ecosystem security. In its 2023 Secure by Design framework, the Cybersecurity and Infrastructure Security Agency (CISA) urges software manufacturers to embrace vulnerability transparency by publishing Common Vulnerabilities and Exposures (CVEs) promptly and maintaining clear disclosure policies, fostering accountability and faster remediation across supply chains.^[7]

Defense in Depth and Fail Securely

Defense in depth is a foundational principle in secure by design that involves deploying multiple, independent layers of security controls to safeguard systems, applications, and data against threats. This strategy ensures that if one layer is breached—such as a firewall or perimeter defense—the attacker must still navigate additional barriers like encryption, intrusion detection systems, and access controls to achieve compromise. Originating from military doctrine, where it emphasizes redundant fortifications to absorb attacks, defense in depth in cybersecurity integrates technical, procedural, and human elements to create resilient protections that slow or stop adversaries at various stages.^[26]^[27]^[2] In enterprise architectures, network segmentation serves as a practical application of defense in depth, partitioning networks into isolated segments based on function or sensitivity to restrict lateral movement by intruders. For instance, separating user networks from critical servers limits the blast radius of a breach, allowing monitoring and response at segment boundaries without exposing the entire infrastructure. This layered approach not only mitigates risks from initial intrusions but also supports ongoing threat detection and recovery efforts.^[28]^[27] The fail securely principle complements defense in depth by requiring systems to default to a denial-of-access or safe shutdown state during failures, errors, or ambiguous conditions, rather than permitting insecure fallbacks that could enable exploitation. Articulated in Saltzer and Schroeder's seminal 1975 paper as "fail-safe defaults," it mandates basing access on explicit permissions, ensuring that design flaws or unexpected events do not inadvertently grant privileges. For example, authentication mechanisms should lock accounts after repeated failed attempts or timeouts, preventing brute-force attacks from succeeding due to error handling lapses.^[29]^[30] In IoT environments, fail securely manifests through tamper-resistant designs that detect physical interference and respond by disabling functionality or erasing sensitive data to avoid cascading compromises. Devices equipped with secure elements or epoxy-encapsulated hardware can trigger alerts or self-destruct mechanisms upon detecting unauthorized access attempts, thereby containing threats without propagating them across connected networks. This principle underscores the need for proactive error states in resource-constrained systems, where single points of failure could otherwise lead to widespread vulnerabilities.^[31]^[29]

Methodologies and Practices

Secure Software Development Lifecycle

The Secure Software Development Lifecycle (SSDLC), also known as the Secure SDLC, integrates security practices into every phase of the traditional software development lifecycle to proactively address vulnerabilities and ensure secure by design principles are embedded from the outset. This approach shifts security responsibilities to developers and stakeholders early, reducing the cost and effort of remediation later, as defects identified post-deployment can be up to 100 times more expensive to fix than those caught during requirements or design. By incorporating security at each stage, organizations can mitigate risks associated with common threats, such as injection attacks or broken access controls, while aligning with broader secure by design goals like least privilege.^[32] In the requirements phase, security is incorporated through the creation of security user stories that explicitly define non-functional security requirements, such as data encryption standards or authentication mechanisms, ensuring that security needs are captured alongside functional specifications from the project's inception. During the design phase, architecture reviews and threat modeling sessions evaluate system components for potential weaknesses, applying principles like defense in depth to create resilient blueprints that minimize attack surfaces. Implementation follows with adherence to secure coding standards, including mitigations for the OWASP Top 10 risks, such as input validation to prevent injection flaws and secure random number generation for cryptographic operations.^[33]^[3] Testing in the SSDLC emphasizes both static application security testing (SAST), which analyzes source code for vulnerabilities without execution, and dynamic application security testing (DAST), which simulates attacks on running applications to identify runtime issues like cross-site scripting. Deployment integrates secure continuous integration/continuous deployment (CI/CD) pipelines that automate vulnerability scans, enforce code signing, and use infrastructure as code with least-privilege access to prevent unauthorized changes. Finally, the maintenance phase focuses on patch management processes to timely apply security updates, monitor for emerging threats, and conduct periodic audits to sustain security posture throughout the software's lifecycle.^[34]^[35]^[32] Key frameworks guide the implementation of SSDLC. Microsoft's Security Development Lifecycle (SDL), first introduced in 2004 and updated as of 2025, provides a structured set of 10 practices spanning requirements analysis to final validation, emphasizing tools for static analysis and fuzzing. Similarly, the NIST Special Publication 800-218 (2022), titled Secure Software Development Framework (SSDF), outlines 17 high-level practices organized into four groups—Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities—to be integrated across any SDLC model, promoting outcomes like reduced vulnerability prevalence through consistent security controls. As of 2025, OWASP has updated its integration standards to include enhanced guidance for AI and machine learning security in the SSDLC.^[36]^[37]^[32]^[38] Supporting tools and practices enhance SSDLC effectiveness, particularly through shift-left security, which moves testing and reviews earlier in the process to detect issues at the source and avoid downstream propagation. Automated code scanning tools like SonarQube integrate into IDEs and CI/CD pipelines to perform real-time analysis for security hotspots and code smells, enabling developers to address flaws immediately. Adoption of these practices prevents accumulation of technical debt and improves overall software reliability.^[39]^[40]^[41]

Threat Modeling and Risk Assessment

Threat modeling is a structured process in secure by design methodologies that involves systematically identifying, categorizing, and prioritizing potential security threats to a system during its early design stages. This approach typically begins with the creation of data flow diagrams (DFDs), which visually represent the system's components, data flows, trust boundaries, and interactions to provide a clear architectural overview. By decomposing the system into these elements, developers can pinpoint vulnerabilities and entry points for attacks.^[42]^[43] A widely adopted framework for mapping threats within these diagrams is STRIDE, developed by Microsoft, which classifies threats into six categories: Spoofing (impersonating a user or system), Tampering (altering data or code), Repudiation (denying actions), Information Disclosure (exposing sensitive data), Denial of Service (disrupting availability), and Elevation of Privilege (gaining unauthorized access levels). For each element in the DFD, the STRIDE model is applied to generate a comprehensive threat list, enabling teams to anticipate adversarial behaviors and design countermeasures accordingly. This method ensures that security considerations are embedded proactively rather than reactively. As of 2025, extensions to threat modeling include specific considerations for AI/ML systems, such as adversarial inputs and model poisoning.^[44]^[43]^[45] Following threat identification, risk assessment evaluates the likelihood and impact of these threats using qualitative or quantitative models. The DREAD model, also originating from Microsoft, assesses risks across five factors—Damage potential, Reproducibility of the attack, Exploitability ease, Affected users scope, and Discoverability of the vulnerability—assigning scores typically on a 1-10 scale to calculate an overall risk rating, with higher scores indicating priorities for mitigation. Complementing this, the Common Vulnerability Scoring System (CVSS), maintained by the Forum of Incident Response and Security Teams (FIRST), provides a standardized numerical score from 0.0 to 10.0 based on metrics like attack vector, complexity, privileges required, and potential impact, facilitating consistent prioritization across organizations. These assessments guide resource allocation toward high-impact threats.^[46]^[47] Tools such as Microsoft's Threat Modeling Tool automate much of this process by supporting DFD creation, STRIDE-based threat generation, and mitigation recommendations, integrating seamlessly into development workflows to foster collaborative security reviews. In practice, applying threat modeling early can mitigate risks like supply chain attacks, as exemplified by the 2021 Log4j vulnerability (CVE-2021-44228), where a flaw in the widely used Apache logging library enabled remote code execution across millions of applications; proactive DFD analysis of third-party dependencies could have identified and isolated such exposure points during design.^[48]^[49] This practice integrates into the broader secure software development lifecycle as a dedicated phase for ongoing threat refinement.^[50]

Standards and Regulations

Key Standards and Frameworks

The National Institute of Standards and Technology (NIST) has developed key frameworks that underpin secure by design principles, notably Special Publication (SP) 800-218, the Secure Software Development Framework (SSDF), released in February 2022.^[51] This framework outlines 19 high-level practices organized into four groups—Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities—that span the entire software development lifecycle (SDLC).^[52] These practices emphasize integrating security from the outset, such as defining security requirements early and conducting vulnerability management, to mitigate risks systematically across preparation, protection, production, and response phases.^[32] Complementing the SSDF, NIST SP 800-53 Revision 5, published in September 2020, provides a comprehensive catalog of over 1,000 security and privacy controls organized into 20 families, including access control and incident response, to protect information systems and support risk-based secure design implementations.^[53] The Open Web Application Security Project (OWASP) contributes significantly through its Secure by Design Framework, initially released as a draft version 0.5.0 in August 2025, which focuses on embedding security into software architecture during the design phase of the SDLC.^[3] This framework offers structured guidance for architects and engineers, including checklists for design-time decisions like establishing trust zones and service boundaries, to prevent security flaws before coding begins and align with regulatory requirements.^[54] Additionally, OWASP's Software Assurance Maturity Model (SAMM), an open framework updated to version 2.0 in 2020 with ongoing enhancements, enables organizations to assess and improve their software security posture through maturity levels across five business functions: governance, design, implementation, verification, and operations.^[55] SAMM uses scoring metrics, such as "Percent to Target," to benchmark practices and identify gaps, supporting tailored strategies for secure development maturity.^[56] International standards like ISO/IEC 27034 provide foundational guidance for application security, with Part 1 (published November 2011) offering an overview of concepts, principles, and processes to integrate security into the management of in-house, acquired, or outsourced applications throughout their lifecycle.^[57] This multi-part standard emphasizes specifying security requirements, selecting controls, and maintaining application security norms to ensure consistent protection against threats.^[58] For benchmarking, the Building Security In Maturity Model (BSIMM), developed by Synopsys and based on empirical data from over 100 organizations, measures software security initiatives across 128 activities in 12 practices, spanning governance, intelligence, secure development lifecycle (SDLC) practices, and deployment. In its latest iteration, BSIMM15 (January 2025), it is based on data from 121 organizations. BSIMM serves as a descriptive tool to compare an organization's maturity against industry peers, highlighting observable behaviors without prescribing specific actions.^[59] The Cybersecurity and Infrastructure Security Agency (CISA) addresses secure by design through its December 2023 whitepaper, "The Case for Memory Safe Roadmaps," co-authored with agencies like the NSA and international partners, which recommends transitioning to memory-safe languages (e.g., Rust, Go, Java) to eliminate up to 70% of vulnerabilities stemming from memory safety issues, such as those in Microsoft CVEs.^[60] The document urges software manufacturers to publish roadmaps detailing phased adoption, training, and prioritization of critical code, reducing the attack surface and operational costs associated with patching exploits.^[61]

Legislative and Policy Developments

In the United States, Executive Order 14028, issued on May 12, 2021, mandates the adoption of secure software development practices across federal agencies and contractors to enhance the nation's cybersecurity posture, emphasizing the removal of default passwords, implementation of multi-factor authentication, and centralized vulnerability management. This order also requires the development of software bills of materials (SBOMs) to improve supply chain transparency and risk assessment for critical software. Building on this, the Cybersecurity and Infrastructure Security Agency (CISA) launched the Secure by Design Pledge in May 2024, with 328 signatories as of November 2025 committing to measurable actions such as eliminating default credentials and prioritizing vulnerability remediation.^[8] Additionally, the Protecting and Transforming Cyber Health Care (PATCH) Act of 2022, enacted in December 2022, requires enhanced vulnerability disclosure requirements for medical device manufacturers, including postmarket monitoring plans and coordinated reporting to address cybersecurity risks.^[62] In the European Union, the Cyber Resilience Act (CRA), adopted in 2024 and entering into force on December 10, 2024, imposes mandatory security-by-design obligations on manufacturers of digital products, requiring vulnerability handling throughout the product lifecycle, conformity assessments, and CE marking for compliance, with main provisions applying from December 11, 2027.^[15] Enforcement mechanisms include market surveillance by national authorities, potential fines up to 15 million euros or 2.5% of global turnover, and harmonized standards to ensure interoperability.^[15] Complementing this, the Digital Operational Resilience Act (DORA), effective from January 17, 2025, targets the financial sector by requiring ICT risk management frameworks that incorporate secure-by-design principles, third-party oversight, and incident reporting to mitigate operational disruptions.^[63] Globally, the United Kingdom's National Cyber Security Centre (NCSC) updated its Secure by Design principles in May 2025 through the Software Security Code of Practice, promoting voluntary adoption of baseline security measures like threat modeling and secure coding for software developers, with government procurement incentives to enforce compliance.^[64] In the healthcare domain, the U.S. Food and Drug Administration (FDA) issued final guidance in September 2023 on cybersecurity for medical devices, mandating premarket submissions that demonstrate secure-by-design controls, including risk management plans and SBOMs to protect against evolving threats.^[65] These developments, including widespread mandates for SBOMs, align briefly with non-binding frameworks like NIST's secure software guidelines to foster consistent enforcement.

Applications in Architectures

Client-Server and Distributed Systems

In client-server architectures, secure by design emphasizes robust authentication mechanisms for APIs to ensure mutual verification between clients and servers, preventing unauthorized access. One key approach is the use of mutual Transport Layer Security (mTLS) with OAuth 2.0, where both parties present certificates during the TLS handshake to authenticate each other, binding access tokens to the client's certificate for enhanced security against token theft or impersonation.^[66] This method, defined in RFC 8705, ensures that only legitimate clients can request and use tokens, reducing risks in distributed API interactions. Additionally, minimizing server privileges aligns with the principle of least privilege, where server processes are granted only the minimal permissions necessary to handle client requests, thereby limiting the impact of exploits originating from compromised clients, such as injection attacks that could otherwise escalate to full system compromise.^[67] Practical implementations in client-server systems include enforcing TLS 1.3 by default for all communications, which mandates forward secrecy and eliminates vulnerable legacy cipher suites, thereby providing stronger encryption and resistance to downgrade attacks out of the box.^[68] For web applications, secure session management is critical to avoid replay attacks, involving the generation of high-entropy session IDs using cryptographically secure pseudorandom number generators, binding sessions to client attributes like IP addresses, and regenerating IDs upon authentication or privilege changes to invalidate any intercepted tokens.^[69] In distributed systems, secure by design extends to microservices architectures through service meshes that automate encryption and identity management across nodes. For instance, Istio implements mutual TLS (mTLS) to encrypt all service-to-service traffic transparently, using short-lived X.509 certificates issued to workloads for identity verification without requiring application code changes.^[70] This approach supports zero-trust models, where no implicit trust exists between nodes regardless of network location, with access decisions made dynamically per request based on policy enforcement points that verify identities and authorize actions continuously.^[71] By assuming potential compromise at any node, these mechanisms prevent lateral movement by attackers and ensure resilient, secure communication in highly decentralized environments. As of 2025, CISA's Secure by Design Pledge, launched in May 2024, encourages adoption of such practices in distributed systems through commitments to automated security testing and transparency measures like software bills of materials (SBOMs).^[4] Additionally, CISA's February 2025 alert highlights eliminating buffer overflow vulnerabilities in distributed software design to mitigate memory safety issues prevalent in these architectures.^[72]

Cloud and IoT Environments

In cloud environments, secure by design principles emphasize integrating security into the architecture from inception, accounting for the shared responsibility model where cloud service providers (CSPs) secure the underlying infrastructure while customers handle applications, data, and configurations.^[73] This approach leverages frameworks like the NIST Secure Software Development Framework (SSDF), which recommends threat modeling during design (PW.1) to identify risks such as data breaches and unauthorized access, ensuring architectures incorporate zero trust principles, network segmentation, and encryption for data at rest and in transit using FIPS 140-2/3 validated cryptography.^[32] For instance, the U.S. Department of Defense Cloud Security Playbook advocates using Infrastructure as Code (IaC) for automated, secure deployments and implementing the principle of least privilege (PoLP) to minimize attack surfaces, with mandatory phishing-resistant multi-factor authentication (MFA) for privileged access.^[73] The Cybersecurity and Infrastructure Security Agency (CISA) Secure by Design guidance further stresses eliminating default passwords, providing free security logging, and publishing threat models to enhance transparency in cloud products, reducing customer burden by embedding protections like memory-safe languages and Transport Layer Security (TLS) for connections.^[7] In practice, this means CSPs must offer secure default configurations and configuration templates at no extra cost, while customers conduct regular penetration testing and deploy Cloud-Native Application Protection Platforms (CNAPPs) for runtime monitoring, as outlined in DoD guidelines to achieve defense-in-depth.^[73] These practices not only mitigate common vulnerabilities but also align with standards like NIST SP 800-53, promoting scalable security in multi-tenant environments.^[32] As of 2025, integrations with NIST's Cybersecurity Framework 2.0 (released 2024) enhance these applications by emphasizing governance and supply chain risk management in cloud architectures.^[74] For Internet of Things (IoT) environments, secure by design focuses on embedding security into device hardware, firmware, and connectivity from the outset, given the resource constraints and vast attack surfaces of interconnected devices. The IoT Security Foundation (IoTSF) Assurance Framework classifies devices into assurance levels (0-4) based on risk assessments of confidentiality, integrity, and availability, mandating secure boot processes, tamper-resistant hardware, and digitally signed firmware updates to prevent unauthorized modifications.^[75] NIST integrates its SSDF with IoT-specific guidance (e.g., NISTIR 8259), recommending the reuse of vetted cryptographic modules (PW.4) and secure default settings (PW.9) to address threats like weak authentication and supply chain compromises.^[32]^[76] CISA's principles apply to IoT by requiring manufacturers to eliminate default credentials, implement unique device identifiers with FIPS 140-2 compliant keys, and provide vulnerability disclosure policies, ensuring a chain of trust across the supply chain.^[7] Best practices include using strong, updateable encryption for interfaces (e.g., WPA-2 AES for wireless) and offering user-controlled update mechanisms, as per IoTSF guidelines, to mitigate risks in deployments like smart homes or industrial sensors.^[75] Compliance with standards such as ETSI EN 303 645 and NIST SP 800-218 enables end-of-life data erasure and auditable manifests of software components, fostering resilience against evolving threats.^[75]^[32] As of September 2024, ETSI EN 303 645 was updated to version 3.1.3, strengthening baseline security provisions for consumer IoT devices against elementary attacks.^[77] Additionally, NIST's draft Revision 1 of IR 8259 (public comment through October 2025) introduces updated foundational cybersecurity activities for IoT manufacturers, including risk-based methodologies.^[78] Both cloud and IoT benefit from overarching practices like executive accountability for security outcomes and radical transparency through Software Bills of Materials (SBOMs), as promoted by CISA, to build ecosystem-wide trust and reduce systemic vulnerabilities.^[7]

References

[1]
[PDF] Principles and Approaches for Security-by-Design and -Default - CISA
Apr 13, 2023 · “Secure-by-Design” means that technology products are built in a way that reasonably protects against malicious cyber actors successfully ...
[2]
Secure Product Design - OWASP Cheat Sheet Series
Security Principles. 1. The principle of Least Privilege and Separation of Duties; 2. The principle of Defense-in-Depth; 3. The principle of Zero Trust; 4. The ...
[3]
OWASP Secure by Design Framework
The OWASP Secure-by-Design Framework provides practical guidance to embed security into software architecture from the start—long before code is written.
[4]
Secure by Design - CISA
Products designed with Secure by Design principles prioritize the security of customers as a core business requirement, rather than merely treating it as a ...Read the Whitepaper · Secure by Design Alerts · Secure by Design Blogs · Pledge
[5]
https://www.cisa.gov/securebydesign/pledge/progress-reports
[6]
[PDF] Secure By Design - CISA
The authoring organizations developed the following three core principles to guide software manufacturers in building software security into their design ...
[7]
Secure by Design Pledge | CISA
No readable text found in the HTML.<|control11|><|separator|>
[8]
https://www.cisa.gov/securebydesign/pledge/secure-design-pledge-signers
[9]
[PDF] Unix and Security: The Influences of History - Purdue e-Pubs
Abstract. UNIX has a reputation as an operating system that is difficult to secure. This reputation is largely unfounded. Instead, the blame lies.
[10]
[PDF] Looking Back at the Bell-La Padula Model
Dec 7, 2005 · The Bell-La Padula security model produced conceptual tools for the analysis and design of secure computer sys- tems. Together with its sibling ...
[11]
About the Microsoft Security Development Lifecycle (SDL)
The Microsoft SDL became an integral part of the software development process at Microsoft in 2004. The development, implementation, and constant ...
[12]
Secure by Design Pledge Signers - CISA
Ivanti. Jobready360, JupiterOne, Keeper Security, Key9 Identity, Kisi, Kiteworks, KnectIQ. Komodo Health, Kontent.ai, Kusari, Lasso Security, Legit Security ...
[13]
Securing our future: April 2025 progress report on ... - Microsoft
Apr 21, 2025 · We are sharing the second SFI progress report, which highlights progress made in our multi-year journey to improve the security posture of Microsoft.Topics · Secure By Design, Default... · A Future Of Secure...
[14]
Cyber Resilience Act | Shaping Europe's digital future
Mar 6, 2025 · The Cyber Resilience Act entered into force on 10 December 2024. The main obligations introduced by the Act will apply from 11 December 2027.Regulation (EU) 2024/2847 · EU cybersecurity policies · European Commission
[15]
Enhance security with the principle of least privilege - Microsoft Learn
Oct 23, 2023 · The information security principle of least privilege asserts that users and applications should be granted access only to the data and operations they require ...Recommendations at a glance · Overprivileged applications
[16]
Role Based Access Control | CSRC
With RBAC, security is managed at a level that corresponds closely to the organization's structure. Each user is assigned one or more roles, and each role is ...Rbac-std-draft.pdfRole Engineering and RBAC ...CSRC MENUPublicationsRole-Based Access Control
[17]
SolarWinds Compromise, Campaign C0024 - MITRE ATT&CK®
Mar 24, 2023 · During the SolarWinds Compromise, APT29 used domain administrators' accounts to help facilitate lateral movement on compromised networks.
[18]
[PDF] NIST SP 800-123, Guide to General Server Security
Removing unnecessary services and applications is preferable to simply disabling them through configuration settings because attacks that attempt to alter ...
[19]
Announcing the all new Attack Surface Analyzer 2.0 - Microsoft
May 15, 2019 · Attack Surface Analyzer 2.0 can help you identify security weaknesses introduced when installing software on Windows, Linux, or macOS.
[20]
Extending SDL: Understanding The Security Guarantees Of Your Apps
Oct 7, 2019 · This state of the software industry goes against the fundamental tenet called Kerckhoffs' Principle, also known as Shannon's Maxim, which ...
[21]
La Cryptographie Militaire — Evervault
This paper is the origin of Kerckhoffs' Principle which states that the security of a cryptosystem must lie in the choice of its keys only.Missing: source | Show results with:source
[22]
[PDF] CRYPTOGRAPHY 2006 THE RISE AND FALL OF DVD ENCRYPTION
Dec 15, 2006 · 5.4 Security through obscurity. There has never been released an official description of the cryptosystem behind CSS. Its creators must have ...
[23]
FIPS 197, Advanced Encryption Standard (AES) | CSRC
Three members of the Rijndael family are specified in this Standard: AES-128, AES-192, and AES-256. Each of them transforms data in blocks of 128 bits.
[24]
Funded open source security work at the Linux Foundation
Aug 10, 2021 · By its very nature, open source enables worldwide peer review, yet while its transparency has the potential for enhanced software security ...
[25]
defense-in-depth - Glossary | CSRC
defense-in-depth ... Definitions: Information security strategy integrating people, technology, and operations capabilities to establish variable barriers across ...
[26]
[PDF] Recommended Practice: Defense in Depth - CISA
In the cybersecurity paradigm, Defense in Depth correlates to detective and protective measures designed to impede the progress of a cyber intruder while.
[27]
Network Segmentation - OWASP Cheat Sheet Series
This cheat sheet is to show the basics of network segmentation to effectively counter attacks by building a secure and maximally isolated service network ...
[28]
The Protection of Information in Computer Systems
f) Least privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job.Missing: duties | Show results with:duties
[29]
https://www.cs.virginia.edu/~evans/cs551/saltzer/
[30]
[PDF] IoTSF Secure Design Best Practice Guides
Make the device circuitry physically inaccessible to tampering, e.g. epoxy chips to circuit board, resin encapsulation, hiding data and address lines under ...
[31]
[PDF] Secure Software Development Framework (SSDF) Version 1.1
This publication has been developed by NIST in accordance with its statutory responsibilities under the. Federal Information Security Modernization Act ...
[32]
integration standards | OWASP in SDLC
Security can be embedded in a SDLC by building on top of previous steps with policies, controls, designs, implementations and tests.1. The Software Development... · 1.2. Design Stage · 1.3. Development Stage
[33]
CI CD Security - OWASP Cheat Sheet Series
CI/CD pipelines and processes facilitate efficient, repeatable software builds and deployments; as such, they occupy an important role in the modern SDLC.
[34]
[PDF] Developer Guide - OWASP Foundation
Feb 2, 2023 · Application Security Testing (IAST, SAST & DAST) and implementing supply chain security, and there ... Refer to the CI/CD Security Cheat Sheet for ...
[35]
Microsoft Security Development Lifecycle (SDL)
The Security Development Lifecycle (SDL) is Microsoft's approach to integrate security into DevOps, applicable to all software development and platforms.Practices · Frequently Asked Questions · Resource List · Getting started
[36]
Microsoft Security Development Lifecycle (SDL)
Sep 29, 2025 · Microsoft SDL consists of seven components, including five core phases and two supporting security activities. The five core phases are ...Training · Design · Verification
[37]
Shift-Left Security: Advancing Early Stage Security Integration - Sonar
By automating code reviews, Sonar provides immediate feedback on the security and quality of the code being written. This not only facilitates early detection ...Missing: density metrics
[38]
What is Shift Left? Testing, Strategy, Security & Principles ... - Sonar
The principle of Shift Left testing is to transpose testing activities earlier within the Software Development Lifecycle (SDLC). This proactive stance allows ...Missing: density metrics
[39]
Beyond cybersecurity awareness: Make a strategic shift to code ...
Oct 29, 2025 · SonarQube makes this shift achievable by integrating code quality and security checks directly into developers' IDEs and CI/CD pipelines.
[40]
Threat Modeling Process - OWASP Foundation
Threat Analysis. It is frequently claimed that “a prerequisite in the analysis of threats is the understanding of the generic definition of risk.” But this is ...
[41]
Uncover Security Design Flaws Using The STRIDE Approach
This article discusses: The importance of threat modeling; How to model a system using a data flow diagram; How to mitigate threats. This article uses the ...
[42]
What is STRIDE in Threat Modeling? - Security Compass
Aug 25, 2025 · STRIDE is a threat modeling framework created by Microsoft that helps teams identify potential security threats by classifying them into six ...
[43]
DREAD Threat Modeling: An Introduction to Qualitative Risk Analysis
Mar 9, 2022 · The DREAD model quantitatively assesses the severity of a cyberthreat using a scaled rating system that assigns numerical values to risk categories.
[44]
CVSS v4.0 Specification Document - FIRST.org
CVSS is an open framework for communicating software vulnerability characteristics and severity, capturing technical details and outputting numerical scores.
[45]
Microsoft Threat Modeling Tool overview - Azure
Aug 25, 2022 · The Threat Modeling Tool is a core element of the Microsoft Security Development Lifecycle (SDL). It allows software architects to identify and mitigate ...Getting StartedStrideGet familiar with the featuresSystem requirementsMitigations
[46]
What is the Log4j Vulnerability? - IBM
The Log4J vulnerability, also known as Log4Shell, is a critical vulnerability discovered in the Apache Log4J logging library in November 2021.
[47]
Microsoft Security Development Lifecycle Threat Modelling
The Microsoft Threat Modeling Tool makes threat modeling easier for all developers through a standard notation for visualizing system components, data flows, ...
[48]
Secure Software Development Framework (SSDF) Version 1.1
Feb 3, 2022 · This document recommends the Secure Software Development Framework (SSDF) – a core set of high-level secure software development practices that can be ...
[49]
What is NIST SSDF and how should you implement it? - Codific
Jan 27, 2025 · The NIST SSDF framework consists of 42 specific tasks across 19 practices, organized into four categories, each addressing critical aspects of ...
[50]
SP 800-53 Rev. 5, Security and Privacy Controls for Information ...
This publication provides a catalog of security and privacy controls for information systems and organizations to protect organizational operations and assets.
[51]
https://csrc.nist.gov/pubs/sp/800/218/final
[52]
OWASP SAMM
SAMM is a Software Assurance Maturity Model that helps organizations analyze and improve their software security posture.
[53]
https://csrc.nist.gov/pubs/sp/800/53/r5/final
[54]
ISO/IEC 27034-1:2011 - Information technology — Security techniques
In stockISO/IEC 27034 provides guidance to assist organizations in integrating security into the processes used for managing their applications.
[55]
https://owaspsamm.org/
[56]
What Is the BSIMM and How Does It Work? - Black Duck
... Building Security In Maturity Model (BSIMM) measures software security. The BSIMM (pronounced “bee simm”) is a study of existing software security initiatives.
[57]
[PDF] The Case for Memory Safe Roadmaps - CISA
Memory safe programming languages (MSLs) can eliminate memory safety vulnerabilities. Therefore, transitioning to MSLs would likely greatly lessen the need to ...
[58]
[PDF] The Case for Memory Safe Roadmaps
Dec 6, 2023 · Memory safe programming languages (MSLs) can eliminate memory safety vulnerabilities. Therefore, transitioning to MSLs would likely greatly ...
[59]
Building a Secure by Design Ecosystem - CISA
Jan 13, 2025 · The Secure by Design movement has ignited tangible improvements in how manufacturers develop and secure software.
[60]
Text - H.R.7084 - 117th Congress (2021-2022): PATCH Act of 2022
“(1) The manufacturer shall have a plan to appropriately monitor, identify, and address in a reasonable time postmarket cybersecurity vulnerabilities and ...
[61]
Digital Operational Resilience Act (DORA) - EIOPA - European Union
The Digital Operational Resilience Act (DORA) is a regulation introduced by the European Union to strengthen the digital resilience of financial entities.EU - 2024/1774 - EN - EUR-Lex · Directive (EU) 2022/2556 · 2022/2554 - EN
[62]
[PDF] Software Security Code of Practice - May 2025 - GOV.UK
This document outlines a voluntary Software Security Code of Practice. The Code of. Practice has been developed to improve the security and resilience of ...
[63]
[PDF] Cybersecurity in Medical Devices: Quality System Considerations ...
Sep 27, 2023 · FDA recommends that device manufacturers implement comprehensive cybersecurity risk management programs and documentation consistent with the QS ...
[64]
RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and ...
This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication ...Table of Contents · Mutual TLS for OAuth Client... · Mutual-TLS Client Certificate...
[65]
least privilege - Glossary - NIST Computer Security Resource Center
A security principle that a system should restrict the access privileges of users (or processes acting on behalf of users) to the minimum necessary to ...
[66]
RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3
This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet.
[67]
Session Management - OWASP Cheat Sheet Series
The session ID regeneration is mandatory to prevent session fixation attacks, where an attacker sets the session ID on the victim user's web browser instead of ...
[68]
Istio / Security
The Istio security features provide strong identity, powerful policy, transparent TLS encryption, and authentication, authorization and audit (AAA) tools.
[69]
[PDF] Zero Trust Architecture - NIST Technical Series Publications
Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area ...
[70]
[PDF] Cloud Security Playbook Volume 1 - DoD CIO
Feb 26, 2025 · Cloud Service Providers are responsible for the physical security of their datacenters. They are also responsible for providing secure services.
[71]
[PDF] IoTSF IoT Security Assurance Framework Release 3.0 Nov 2021
Providing good security capability requires decisions upfront in design and use – often referred to as secure by design. In most cases, addressing the security ...
[72]
SSDF and IoT Cybersecurity Guidance: Building Blocks for IoT ...
Jun 22, 2023 · When used together, NIST's SSDF and IoT cybersecurity guidance help manufacturers design and deliver more secure IoT products to customers.