{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"security/security-by-design","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/security/security-by-design/","da":"https://cmaintz.github.io/tech-atlas/da/terms/security/security-by-design/"},"term":{"en":"Security by design","da":"Security by design"},"aka":{"en":["secure by design"],"da":["indbygget sikkerhed"]},"domain":["security"],"cluster":"fundamentals","status":"current","summary":{"en":"Thinking security into systems and processes from the very start, instead of adding it at the end.","da":"At tænke sikkerhed ind fra starten i systemer og processer i stedet for at tilføje den til sidst."},"body":{"formal":{"en":"The principle that security needs are set out and met in every stage of building a system or process - from first idea through design, building and running it - with safe settings as the default.","da":"Princippet om, at sikkerhedsbehov fastlægges og opfyldes i alle faser af at bygge et system eller en proces - fra den første idé over design og udvikling til drift - med sikre indstillinger som standard."},"plain":{"en":"Like planning the wiring before the walls go up - doing it later means tearing down walls.","da":"Som at planlægge ledningerne, før væggene sættes op - gør man det bagefter, må man rive vægge ned."},"inPractice":{"en":"Before a Danish municipality has a new self-service portal built for citizens, the project group requires MFA for staff logins and storing as little personal data as possible, and writes both into the supplier contract.","da":"Før en kommune får bygget en ny selvbetjeningsportal til borgerne, kræver projektgruppen MFA til medarbejdernes login og så få personoplysninger som muligt, og skriver begge dele ind i kontrakten med leverandøren."},"whyItMatters":{"en":"Fixing a weakness after launch costs far more than avoiding it on paper, and some weaknesses cannot be fixed at all without starting over.","da":"Det koster langt mere at rette en svaghed efter lancering end at undgå den på tegnebrættet, og nogle svagheder kan slet ikke rettes uden at starte forfra."}},"deepDive":{"en":"Security by design is the principle that security requirements are derived, implemented and verified throughout a system's development lifecycle rather than bolted on before release, and that systems ship in a secure configuration by default. It is often paired with the related idea of secure by default: the shipped state minimises attack surface (unnecessary services off, no default passwords, least-privilege defaults, encryption on) so that a user who changes nothing is still reasonably protected. The economic argument is well established: defects are far cheaper to remove early, and some architectural weaknesses - a flawed trust model, missing tenant isolation, an authentication scheme that cannot be retrofitted - cannot be patched later without redesign, which is why the discipline emphasises the requirements and design phases, not just secure coding.\n\nIn engineering practice this is operationalised through a secure development lifecycle (Microsoft SDL, OWASP SAMM, BSIMM as a maturity yardstick). Core activities include threat modelling during design (STRIDE to enumerate spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege; attack trees; data-flow diagrams with trust boundaries), abuse-case analysis alongside use cases, and the selection of proven design principles articulated by Saltzer and Schroeder in 1975 - economy of mechanism, fail-safe defaults, complete mediation, open design, least privilege, separation of privilege, least common mechanism and psychological acceptability. Later phases add secure coding standards, SAST and DAST in the pipeline, software composition analysis for dependencies, and security testing gates before release. NIST SP 800-160 Vol. 1 (Engineering Trustworthy Secure Systems) provides the systems-engineering framing.\n\nThe concept has moved from good practice toward obligation. GDPR Article 25 makes \"data protection by design and by default\" a legal requirement for personal-data processing, so privacy-relevant design decisions must minimise data and default to the most protective settings. The EU Cyber Resilience Act imposes essential cybersecurity requirements on products with digital elements, including secure-by-default configuration and vulnerability handling, with obligations phasing in and the reporting duties applying from 11 September 2026. CISA's international \"Secure by Design\" guidance further pushes the responsibility toward manufacturers rather than end users. NIS2 Article 21 reinforces the same expectation for essential and important entities.\n\nA persistent misconception equates security by design with merely running a penetration test before launch; testing at the end validates but cannot substitute for design decisions already baked in, and a pentest that finds an architectural flaw usually finds it too late to fix cheaply. Another is treating \"secure by default\" as absolute - defaults reduce risk for the median deployment but cannot anticipate every environment, so documented hardening guidance still matters. Security by design differs from defence-in-depth (which layers runtime controls) in that it concerns how the system is conceived and built; the two are complementary, since good design decides where those layers belong.","da":"Security by design er princippet om, at sikkerhedskrav udledes, implementeres og verificeres gennem hele systemets udviklingslivscyklus frem for at blive sat på lige før udgivelse, og at systemer leveres i en sikker konfiguration som standard. Det parres ofte med den beslægtede idé secure by default: den leverede tilstand minimerer angrebsfladen (unødvendige tjenester slået fra, ingen standardadgangskoder, least-privilege som standard, kryptering slået til), så en bruger, der ikke ændrer noget, stadig er rimeligt beskyttet. Det økonomiske argument er veletableret: fejl er langt billigere at fjerne tidligt, og nogle arkitektoniske svagheder - en fejlagtig tillidsmodel, manglende adskillelse mellem lejere, en autentificeringsmodel, der ikke kan eftermonteres - kan ikke patches senere uden redesign, og derfor lægger disciplinen vægt på krav- og designfaserne, ikke kun på sikker kodning.\n\nI ingeniørpraksis operationaliseres dette gennem en secure development lifecycle (Microsoft SDL, OWASP SAMM, BSIMM som modenhedsmålestok). Kerneaktiviteter omfatter trusselsmodellering under design (STRIDE til at opregne spoofing, tampering, repudiation, information disclosure, denial of service og elevation of privilege; attack trees; dataflowdiagrammer med tillidsgrænser), analyse af misbrugstilfælde ved siden af use cases og valg af gennemprøvede designprincipper, som Saltzer og Schroeder formulerede i 1975 - economy of mechanism, fail-safe defaults, complete mediation, open design, least privilege, separation of privilege, least common mechanism og psychological acceptability. Senere faser tilføjer standarder for sikker kodning, SAST og DAST i pipelinen, software composition analysis af afhængigheder og sikkerhedstest-gates før udgivelse. NIST SP 800-160 Vol. 1 (Engineering Trustworthy Secure Systems) leverer den systemtekniske indramning.\n\nBegrebet har bevæget sig fra god praksis mod pligt. GDPR artikel 25 gør \"databeskyttelse gennem design og gennem standardindstillinger\" til et lovkrav ved behandling af personoplysninger, så privatlivsrelevante designbeslutninger skal minimere data og som standard vælge de mest beskyttende indstillinger. EU's Cyber Resilience Act stiller væsentlige cybersikkerhedskrav til produkter med digitale elementer, herunder secure-by-default-konfiguration og håndtering af sårbarheder, med forpligtelser, der indfases, og indberetningspligter, der gælder fra 11. september 2026. CISA's internationale \"Secure by Design\"-vejledning skubber yderligere ansvaret over på producenterne frem for slutbrugerne. NIS2 artikel 21 understøtter samme forventning for væsentlige og vigtige enheder.\n\nEn vedholdende misforståelse sætter lighedstegn mellem security by design og blot at køre en penetrationstest før lancering; test til sidst validerer, men kan ikke erstatte designbeslutninger, der allerede er indbygget, og en pentest, der finder en arkitektonisk fejl, finder den typisk for sent til at rette billigt. En anden er at opfatte \"secure by default\" som absolut - standardindstillinger sænker risikoen for det gennemsnitlige setup, men kan ikke foregribe ethvert miljø, så dokumenteret hærdningsvejledning er stadig vigtig. Security by design adskiller sig fra defence-in-depth (der lagdeler kontroller under drift) ved at handle om, hvordan systemet undfanges og bygges; de to supplerer hinanden, for godt design afgør, hvor de lag skal placeres."},"edges":[{"type":"requires","to":"security/cia-triad","confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/vulnerability","why":{"en":"Weaknesses caught at the planning stage never make it into the finished system.","da":"Svagheder, der fanges allerede i planlægningen, når aldrig ind i det færdige system."},"confidence":"high","strength":"primary"},{"type":"used-with","to":"security/zero-trust","confidence":"high","strength":"normal"}],"depth":1,"sources":[{"title":"Cyber Security Fast Track - Ordliste","tier":"course-material"},{"title":"NIST SP 800-160 Vol. 1 Rev. 1 - Engineering Trustworthy Secure Systems","tier":"standard","publisher":"NIST"}],"draft":true}