6 Security-by-Design Principles
Principles as Evidence-Bound Review Questions
IoT security design principles, security by design, least privilege, secure defaults, fail secure, complete mediation, security evidence
6.1 In 60 Seconds
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
- A principle is a question: least privilege, secure defaults, complete mediation, defense in depth, and fail-secure behavior each ask for different evidence.
- The boundary matters: a device, gateway, cloud API, broker, mobile app, or recovery path can each make a different security decision.
- Denied cases carry the proof: allowed-only testing shows convenience, not control.
- Layer independence matters: several controls help only when one shared assumption cannot defeat them all at once.
- A review record needs limits: evidence, residual risk, and retest triggers keep a security claim from drifting as the system changes.
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?
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
- “We follow least privilege” is a slogan until the review shows which actions the identity is denied.
- Secure defaults mean the safer state is the starting point, not an optional hardening task done later.
- Several controls that all depend on the same unchecked path are not defense in depth; they are one control with several labels.
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.
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
- Economy of mechanism asks whether the design can be made smaller and easier to verify without losing necessary protection. A control nobody can fully review is hard to trust.
- Open design asks whether the system stays defensible when its architecture is understood. Security should rest on protected secrets such as keys and on reviewed controls, not on hidden behavior. Secrecy of the design itself is not a control, because design details leak through documentation, staff turnover, and reverse engineering.
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
- Listing principles without controls. A principle with no boundary, control, or evidence is decoration.
- Calling shared-dependency controls “defense in depth.” Independence, not count, is what matters.
- Testing only the allowed action. The denied case carries the proof.
- Forgetting reset, recovery, debug, update, and management paths. These are where secure defaults and complete mediation quietly fail.
- Leaving temporary exceptions and retest triggers out of the record. An undocumented exception silently weakens every related claim.
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
- Security-by-design principles are useful when they produce review evidence, not when they appear as slogans.
- Treat each principle as a question about a specific action, boundary, and control.
- The evidence loop runs from a narrow claim to boundary, control, allowed and denied evidence, decision, and retest trigger.
- Defense in depth depends on independence: layers that share one unprotected assumption fail together.
- Open design relies on protected secrets and reviewed controls, not on hidden behavior.
- Allowed-only testing proves convenience; the denied case carries the proof of the principle.
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.