6 Security-by-Design Principles
6.1 In 60 Seconds
Deny One Unsafe Update Before Trusting a Principle
Picture a door controller offered an old software file by a valid service account. A slogan such as “secure by design” helps only when the device rejects this exact case and records why.
Firmware means the software stored on a device. Telemetry means measured status sent from a device for remote use. Each protected action needs a named boundary, control, allowed case, and denied case.
Try the correct file, a changed file, an old version, a wrong role, a lost service, and a restart. Record identity, version, policy result, device state, alert, owner, and retest trigger.
This runway does not prove that one principle secures the whole product. The deeper sections turn least privilege, safe defaults, full checks, layered controls, and safe failure into reviewable evidence.
Security by design starts with a small, testable claim. A team can say “we use least privilege” or “we have defense in depth,” but those words do not protect a device until someone names the action, the boundary, the control, and the evidence. For an IoT product, that action might be installing firmware, changing a lock schedule, accepting telemetry, or opening a management port.
Start simple. Pick one action and write the review question in plain words: “Who is allowed to do this, where is the decision made, what proves the allowed case, and what proves the denied case?” If the team can answer that question, the principle is useful. If it cannot, the principle is still only a slogan.
6.2 Key Ideas
Taken together, these checks make the section reviewable. That order prevents a control name from being treated as proof and connects the visual to the chapter’s evidence-led review sequence.
6.3 Turn the Slogan Into a Review Question
Security-by-design is reviewable only when each principle is tied to evidence. A useful review does not stop at "we follow least privilege" or "we use defense in depth." It records the protected action, the trust boundary, the control that enforces the principle, the evidence that the control is active, the residual risk, and the trigger that requires retesting.
The important idea is to treat every principle as a question about a specific action, path, or asset. Principles earn their value by preventing vague security claims, not by appearing in a design document.
If you only need the intuition, this layer is enough: a principle is a review question. "The system is secure by design" is too broad to test. "Firmware install requires a signed manifest, device-side policy acceptance, and an install-state record" is reviewable.
For an IoT product, the review question should name the real boundary. A sensor joining a gateway, a mobile app changing a lock schedule, a broker accepting a publish request, and a device installing firmware are different decisions. They may all cite the same principle, but each needs its own control and evidence. This is why design principles belong in the architecture record beside assets, identities, paths, tests, logs, and retest triggers.
Each principle reduces to a single question. Least privilege: what is the narrowest permission that still lets this identity do its job? Secure defaults: what happens before anyone changes settings? Complete mediation: is every sensitive request checked, or can a cached or alternate path bypass policy? Defense in depth: if this control fails, what independent control still limits impact? Fail secure: when the control cannot decide safely, does the system move to a documented low-risk state?
This is the point where Turn the Slogan Into a Review Question must connect to observable behavior. Figure 6.1 makes that connection by depicting how the evidence loop turns one principle into a reviewable path: protected action, principle question, boundary, control, allowed and denied evidence, decision and limit, then retest trigger.
The path through Figure 6.1 is meaningful because its labels are specific: Protected action, default, layer, then record limits before reuse. Their roles make visible how the evidence loop turns one principle into a reviewable path: protected action, principle question, boundary, control, allowed and denied evidence, decision and limit, then retest trigger. That mechanism is the part of Turn the Slogan Into a Review Question the chapter continues to build upon.
6.3.1 One Action, One Principle, One Proof
Name the action
State the protected action narrowly: send a configuration change, accept telemetry, install firmware, read a data stream.
Pick the principle
Choose the principle that answers the risk: identity scope, default state, mediation, layering, or failure behavior.
Demand evidence
Require both the allowed case and the denied case, plus residual risk and a retest trigger, before accepting the claim.
6.3.2 Make the Claim Testable
Taken together, these checks make the section reviewable. That order prevents a control name from being treated as proof and connects the visual to the chapter's evidence-led review sequence.
6.3.3 Overview Knowledge Check
If you can restate a principle as a testable question, you can stop here. Continue to Practitioner to run the evidence loop on real controls.
6.4 Follow the Evidence at One Boundary
Security principles usually appear at gates: identity, authorization, input, update, management, and monitoring gates. A gate is useful only when the review can show who reaches it, what it checks, what it allows, what it denies, and what record it leaves.
Run the review on one decision at a time. For a firmware update gate, the boundary might be the device-side verifier that accepts or rejects an install package. The least-privilege question asks which updater identity may submit the package. The secure-defaults question asks what happens before provisioning. Complete mediation asks whether recovery, factory, and debug install paths reach the same verifier. Fail-secure behavior asks whether a missing policy, expired certificate, bad signature, or interrupted install leaves the device in a known safe state. The evidence is not a principle name; it is the allow test, deny test, install log, rollback record, and retest trigger.
Write the claim in the same words an operator or test harness will use, so evidence can be repeated without guessing what the reviewer meant.
6.4.1 Build the Review Record
- State the claim narrowly. Name the protected action and the principle being applied.
- Name the trust boundary. The gateway rule, broker policy, firmware verifier, API handler, or approval path where the decision is made.
- Identify the control. The specific mechanism that enforces the principle at that boundary.
- Collect evidence. Allow logs, deny logs, configuration, policy files, tests, and approval records.
- Record the decision. The accepted claim, its limits, and the residual risk.
- Define the retest trigger. The change that invalidates the review.
Build the Review Record introduces a boundary that must remain visible in the design. Figure 6.2 clarifies it by depicting how “Boundary gates: identity, authorization, input validation, and monitoring guard the protected action and leave a record” is explicit in the diagram.
Read Identity as the first explicit role in Figure 6.2; valid state? supplies the next constraint, while trigger records the consequence. This label-specific chain shows “Boundary gates: identity, authorization, input validation, and monitoring guard the protected action and leave a record” is explicit in the diagram. That is why Build the Review Record matters to the chapter’s later acceptance decision.
6.4.2 What Each Principle Asks
Least privilege
Scope permissions to the reviewed action: a device identity publishes telemetry but cannot subscribe to other classes' commands. Evidence: access rules, topic policies, deny logs, failing tests for unrelated actions. Retest on role, topic, or gateway change.
Secure defaults
Make the first state narrow: management disabled until configured, no shared admin credential, deny-by-default flows, logging on before production. Evidence: first-boot config, provisioning records, tests that unsafe access is unavailable before setup.
Complete mediation
Every sensitive action reaches the policy check; no cache, debug route, or legacy API skips it. Evidence: request-path maps, enforcement locations, denied-request logs, tests against alternate paths.
Defense in depth
Independent controls each answer a different question. Evidence: control maps, failure-mode reviews, and tests that a second control still limits impact when the first is unavailable.
Fail secure
Failure moves the action to a documented low-risk state: reject an update, queue a command, isolate an interface, deny access. Evidence: failure-mode tests, reject logs, recovery records.
Separation of privilege
A sensitive action requires more than one independent condition: identity plus management-zone origin, signed manifest plus version policy, operator role plus change ticket. Evidence: approval records and tests that one missing condition blocks the action.
6.4.3 Example: A Configuration Change
A device management service can send configuration changes to deployed devices. A weak review accepts the claim because the architecture document says "least privilege" and "defense in depth." A stronger review records concrete evidence.
The same pattern applies when the protected action is not a management command. A telemetry ingest service should prove that one device cannot publish as another device, a mobile app should prove that guest users cannot reach owner actions, and a gateway should prove that maintenance commands are refused outside the management role. In each case, ask for both positive and negative evidence, with timestamps and policy identifiers. Store those artifacts with the review record so a later reviewer can rerun the same boundary test. The negative evidence is often the most important artifact because it proves the boundary rejects paths the architecture says should not exist.
6.4.4 Practitioner Knowledge Check
If you can run the evidence loop and check denied cases, you can stop here. Continue to Under the Hood for the principles that govern independence and openness.
6.5 Check Whether the Layers Still Stand
The deeper layer covers the principles that decide whether a layered design is genuinely strong and why allowed-only testing is misleading.
6.5.1 Economy of Mechanism and Open Design
Taken together, these checks make the section reviewable. That order prevents a control name from being treated as proof and connects the visual to the chapter's evidence-led review sequence.
6.5.2 Independence Is the Hard Part of Defense in Depth
Layers are weak when they share an unprotected assumption. The independence test is simple: pick one layer, assume it fails, and check that another layer still limits access, detects misuse, or restores a trusted state.
6.5.3 The Denied Case Carries the Proof
A review that observes only the expected successful action proves convenience, not control. The denied case is where the principle lives: least privilege is shown by the actions that fail, complete mediation by the alternate path that is still blocked, and fail-secure by the state after a forced failure. Equating an encrypted channel with authorization is a related error; encryption protects confidentiality and integrity in transit but says nothing about whether the requester is permitted to act.
6.5.4 Common Mistakes
Taken together, these checks make the section reviewable. That order prevents a control name from being treated as proof and connects the visual to the chapter's evidence-led review sequence.
6.5.5 Under-the-Hood Knowledge Check
At this depth, security-by-design is a set of testable questions whose answers live in the denied cases, the independence of layers, and the documented behavior on failure. A defensible chapter-level claim names the control, the evidence, the limit, and the retest trigger.
6.6 Summary
Taken together, these checks make the section reviewable. That order prevents a control name from being treated as proof and connects the visual to the chapter’s evidence-led review sequence.
6.7 Key Takeaway
Security design principles become practical when least privilege, secure defaults, complete mediation, defense in depth, fail-secure behavior, and separation of privilege are each tied to a boundary, a control, and evidence for both the allowed and denied cases.
6.8 See Also
Cyber Security Defense in Depth
Expand the independent-control review that underpins the layering principle.
Threat Modelling and Mitigation
Connect principles to specific threats and mitigation evidence.
Security Overview Architecture
See where these principles appear across device, network, application, and management layers.