Cybersecurity begins with one fundamental question:
What Are We Trying to Protect — and From What?
Before selecting:
Secure Element
TPM
TEE
AES
TLS
or any other security mechanism,
the engineering team must understand:
Assets
Attackers
Interfaces
Trust Boundaries
Failure Consequences
Lifecycle
because:
Security Technology Without a Threat Model Can Protect the Wrong Thing.
365PCB Product Cybersecurity Design should therefore approach security as:
Start With the Product
First understand:
What does the product do?
What can it control?
What information does it contain?
Who is allowed to use it?
What happens if it is compromised?
Can it be remotely updated?
How long will it remain deployed?
Security Requirements Follow Product Consequence.
Asset Identification
Security begins by identifying:
What Has Value?
Potential assets can include:
You Cannot Protect an Asset You Have Not Identified.
Asset ≠ Data Only
An asset can also be:
For example:
ability to update firmware.
ability to configure a machine.
ability to change operating mode.
Control Privilege Can Be More Valuable Than Stored Data.
Security Objectives
Common security objectives include:
Who may read?
Who may change?
Will the system remain usable?
Who created this data/software?
Who may perform this action?
Cybersecurity Is More Than Encryption.
Safety Interaction
If software controls physical behavior:
Cybersecurity Failure Can Become Physical-System Failure.
Therefore product cybersecurity may interact with:
functional safety
electrical safety
machinery safety
depending on application.
Threat Modeling
Threat modeling asks:
What can go wrong?
Where can it happen?
What would the consequence be?
What controls reduce the risk?
Threat Modeling Converts “Security” Into Engineering Questions.
Threat Model Before Schematic Freeze
Do not wait until:
to discover:
We need secure key storage.
because that requirement may change:
memory
secure element
PCB architecture.
Cybersecurity Can Be a Hardware Requirement.
System Data-Flow Diagram
Map:
Then identify:
Where Trust Changes.
Trust Boundary
A trust boundary exists where data crosses between areas with different trust assumptions.
Examples:
Every Trust Boundary Deserves Security Review.
Attack Surface
Attack surface includes every place where external influence can enter.
Examples:
Ethernet
Wi-Fi
Bluetooth
USB
UART
debug ports
update mechanisms
web interfaces
cloud APIs.
Every Interface Is Also a Potential Security Interface.
Unused Interface
The easiest interface to secure may be:
The Interface the Product Does Not Expose.
Reduce unnecessary:
services
protocols
ports
debug functionality.
Attack Surface Reduction Is Security by Architecture.
Secure by Design
CISA's Secure by Design guidance places responsibility increasingly on product manufacturers rather than expecting users to compensate for insecure defaults, and its 2025 product-security guidance explicitly encourages manufacturers to avoid high-risk practices across product properties, security features, and organizational processes.
Security Burden Should Not Be Shifted Entirely to the Customer.
Secure by Default
A product should begin in an appropriately secure configuration.
Not:
insecure until customer finds page 117 of the manual.
Default Configuration Is Security Architecture.
Default Passwords
Shared universal credentials create fleet-scale risk.
CISA's Secure by Design guidance specifically encourages eliminating default passwords in favor of approaches such as device-unique or user-established credentials where appropriate.
One Password Should Not Unlock an Entire Product Generation.
Unique Device Identity
Every connected production unit should ideally have a unique identity where the architecture requires it.
Identity Should Scale Per Device — Not Per Product Model.
Authentication
Authentication answers:
Who Are You?
Possible identities include:
device
user
service
technician.
Authorization
Authorization answers:
What Are You Allowed to Do?
A logged-in user may be permitted to:
but not:
Update Firmware.
Authentication Without Authorization Is Incomplete Security.
Least Privilege
Give every:
process
user
device
service
only the privileges required.
Don't Give Administrator Authority to Software That Only Needs to Read Temperature.
Role-Based Authorization
Possible roles:
Operator
Administrator
Service Engineer
Read Only
depending on product.
Different Responsibilities Need Different Authority.
Machine Identity
Cloud services and devices also need:
Non-Human Identity.
Security architecture is not only about user passwords.
Device Identity
A device identity can potentially bind:
Serial Number
Certificate
Private Key
Manufacturing Record
Digital Identity Should Correspond to the Physical Product.
Identity Lifecycle
Identity goes through:
Device Identity Has a Lifecycle.
Hardware Root of Trust
Suitable hardware can anchor critical security decisions.
Possible foundations depend on platform and can include:
immutable ROM
protected fuses
secure storage
secure element
TPM-class hardware.
Software Trust Should Begin From Something Harder to Rewrite Than Ordinary Application Flash.
Root of Trust for Boot
Answers:
Which Software Is Authorized to Run?
This directly connects Page 33.
Root of Trust for Storage
Answers:
Which Keys or Secrets Can Be Reliably Protected?
Root of Trust for Identity
Answers:
How Can the Device Prove It Is the Original Device?
Secure Boot
Secure Boot verifies software before execution.
Conceptually:
Trust Extends Through the Boot Chain.
Protect, Detect, Recover
NIST SP 800-193 organizes platform firmware resilience around three major capabilities:
from unauthorized firmware changes.
This is an excellent product-security principle far beyond PC firmware.
Secure Update
A secure product also needs an authenticated path for:
Authorized Change.
Secure Boot Without Secure Update Eventually Creates an Unmaintainable Product.
Anti-Rollback
An older image may be correctly signed but contain:
A Known Vulnerability.
Therefore security-version policy may need to prevent unauthorized downgrade.
Recovery
If current firmware is damaged:
Can the Product Return to a Trusted State?
Security without recovery can create:
Securely Bricked Hardware.
Recovery Must Remain Secure
Recovery mode should not simply become:
signature verification disabled.
Emergency Mode Is Still a Privileged Security State.
Cryptography
Cryptography can provide:
Confidentiality
Integrity
Authentication
Digital Signatures
depending on primitive/protocol.
Different Cryptographic Tools Solve Different Problems.
Don't Invent Cryptography
Use mature, reviewed:
algorithms
libraries
protocols
appropriate to the target ecosystem.
Proprietary Encryption Is Not Automatically Strong Encryption.
Algorithm Selection
Selection should consider:
security strength
processor capability
ecosystem
lifecycle.
Cryptography Is a Product-Lifecycle Decision.
Crypto Agility
A long-life product may eventually need:
new algorithm
new key
new certificate authority.
Security Architecture Should Be Able to Evolve.
Encryption at Rest
Sensitive stored information may require protection.
But the engineering question remains:
Where Is the Decryption Key?
Encryption in Transit
Network data can use authenticated secure transport where appropriate.
Protect the Communication Channel — Not Only the Cloud Database.
Integrity
Data can remain public but still require:
Protection Against Modification.
Digital Signature
Digital signatures are particularly important for:
firmware
critical configuration
where source authorization matters.
Authentication of Software Is Different From Encryption of Software.
Randomness
Cryptographic systems depend on high-quality:
Entropy.
Poor randomness can undermine otherwise correct algorithms.
Hardware Random Number Generator
Some MCUs/SoCs include entropy/randomness hardware.
But:
Presence of a Peripheral Does Not Eliminate the Need for Correct Software Integration.
Key Management
A secure algorithm with insecure key handling becomes:
An Insecure System.
Key Generation
Ask:
Where was this key generated?
Was it ever exposed?
Key Lifecycle Begins at Creation.
Key Storage
Private keys should not casually exist in:
source repositories
log files
firmware images
production spreadsheets.
Secrets Should Be Treated as Secrets Everywhere.
Key Provisioning
How does each manufactured product receive its keys?
Cybersecurity Becomes Manufacturing Engineering.
Key Rotation
Long-life products need mechanisms for:
Replacing Trust Material.
Key Revocation
If one key is compromised:
Can the System Stop Trusting It?
Root-Key Compromise
This represents a much larger event than one device-key compromise.
Key Hierarchy Should Limit Blast Radius.
PKI
Large fleets can use hierarchical trust:
Trust Can Be Scaled Without Sharing One Universal Secret.
Certificate Lifecycle
Certificates:
expire
renew
revoke.
Certificate Expiration Should Not Be a Surprise Fleet Outage.
Mutual Authentication
Depending on architecture:
and:
Server authenticates device.
Trust Can Be Bidirectional.
Secure Storage
A product can contain secrets such as:
device keys
credentials
proprietary configuration.
Storage Protection Must Match Asset Value.
Secure Element
Where justified, a dedicated security device can isolate cryptographic material from ordinary application software.
Reduce the Number of Places Where the Secret Exists.
TPM
TPM-class hardware can support:
keys
measurements
attestation
on suitable platforms.
Hardware Identity Can Extend Into System Integrity Evidence.
TEE
A Trusted Execution Environment can isolate selected trusted operations from ordinary OS software.
Not Every Application Needs Access to Every Secret.
TrustZone Architecture
On supported processors, secure/non-secure execution domains can provide hardware-enforced separation.
Hardware Isolation Can Create Stronger Software Boundaries.
TEE Is Not Magic
Poor:
secure-world code
key policy
can still undermine the system.
Security Hardware Requires Security Architecture.
MPU
On MCU systems, a Memory Protection Unit can constrain task access to memory regions where RTOS/platform supports it.
Memory Isolation Can Reduce Fault Propagation.
MMU
Linux-class processors can provide process-level virtual memory isolation.
Process Boundaries Are Security Boundaries.
Privilege Levels
Separate:
from:
Ordinary Application Code.
Keep Powerful Execution Domains Small.
Kernel Attack Surface
Linux kernel drivers run with substantial privilege.
Every Kernel Driver Expands Trusted Computing Base.
This directly connects Page 29.
Userspace Where Possible
Functionality not requiring kernel privileges can often live outside kernel space.
Minimize Privileged Code.
Process Isolation
Split major services according to:
trust
responsibility
recovery.
One Compromised Service Should Not Necessarily Compromise the Entire Product.
Container Isolation
Containers may offer useful process/deployment boundaries on larger platforms.
But:
Container ≠ Security Boundary by Default.
Correct kernel, privilege and policy configuration still matters.
Linux Capabilities
Instead of full root privileges:
Give a Process Only the Specific Privilege It Needs.
SELinux / AppArmor
Mandatory access-control frameworks can impose policy on process behavior.
Security Policy Can Be Enforced by the Operating System.
seccomp
System-call restrictions can reduce the kernel interfaces exposed to a service.
Reduce What a Compromised Process Can Ask the Kernel to Do.
Memory Safety
Many serious software vulnerabilities arise from:
out-of-bounds access
use-after-free
buffer overflows
and related memory-safety defects.
Memory-Safe Languages
CISA has explicitly encouraged software manufacturers to consider memory-safe development strategies and publish migration roadmaps where relevant; its updated 2025 product-security guidance also treats unnecessary use of memory-unsafe languages for certain new critical-infrastructure product lines as a high-risk practice when practical alternatives exist.
Eliminating a Vulnerability Class Is Better Than Detecting Every Instance Forever.
Embedded Reality
Embedded development still has enormous existing:
ecosystems.
The professional conclusion is not:
Rewrite everything tomorrow.
It is:
Deliberately Reduce Memory-Safety Risk Where Architecture, Toolchain and Lifecycle Permit.
Rust Direction
Rust may be useful for selected new embedded/Linux components where:
target support
ecosystem
engineering team
are appropriate.
Language Choice Is One Security Control — Not the Whole Security Program.
Safe C / C++
Existing C/C++ systems still benefit from:
strict coding
compiler protections
static analysis
testing.
Legacy Language Does Not Excuse Legacy Engineering.
Bounds Checking
Externally controlled lengths and indexes should be validated.
Never Let an Untrusted Length Become an Unbounded Memory Operation.
Integer Safety
Parsing:
packet lengths
image sizes
offsets
requires attention to overflow and range.
Small Arithmetic Errors Can Become Large Security Failures.
Input Validation
Every external interface receives:
Untrusted Input.
Including:
Network
USB
Configuration
Sensor Metadata
Cloud Messages
Parse Defensively
A message can be:
too short
too long
malformed
unsupported.
Invalid Input Should Produce Controlled Rejection.
State Validation
A packet can be syntactically valid but logically invalid in current state.
Protocol Correctness Is Not Product Authorization.
Range Validation
Command:
temperature_limit = impossible value
should not be accepted merely because the binary representation is valid.
Security Validation Should Understand Product Semantics.
Command Freshness
A previously valid command can become dangerous if replayed later.
Authentic ≠ Fresh.
Replay Protection
Depending on protocol:
sequence
nonce
session
can contribute to freshness.
Authorization Needs Time Context.
Session Management
Authenticated sessions need:
creation
timeout
termination.
Old Authentication Should Not Live Forever Without Policy.
Rate Limiting
A valid client can still overload a service.
Authentication Does Not Prevent Resource Exhaustion.
Resource Availability
Cybersecurity also includes keeping product resources usable.
IEC 62443-4-2 explicitly includes resource availability among its seven foundational component-security requirements.
Availability Is a Security Property.
Resource Limits
Bound:
connections
queues
messages
logs
where necessary.
Every Resource Needs a Failure Policy.
Watchdog
A watchdog helps recover certain software hangs.
But:
Recovery Is Not Root-Cause Prevention.
Use it as one resilience layer.
Network Attack Surface
Review:
open ports
running services
discoverability
management interfaces.
If a Service Is Not Needed, Don't Run It.
Service Binding
Ask:
Does this administrative service really need to listen on every network interface?
Network Reachability Should Be Intentional.
Local vs Remote Administration
Some powerful operations may require:
local physical presence
depending on product.
Not Every Administrative Function Needs Internet Reachability.
Web Interface
Embedded web interfaces need the same basic security discipline as larger applications:
authentication
authorization
input validation
session management.
Small Device Does Not Mean Small Web Risk.
API Security
Mobile applications often call backend APIs.
The Mobile App Is Not the Security Boundary.
Server must independently enforce authorization.
Cloud API
Never assume:
user cannot see this button
means:
user cannot call this API.
Security Lives Behind the Interface.
Bluetooth
Wireless pairing/authentication architecture should follow product risk.
Physical Proximity Does Not Automatically Equal Authorization.
Wi-Fi
Network credential storage and onboarding deserve deliberate protection.
Connectivity Credentials Are Product Secrets.
Cellular
Modem/control channels can create additional:
firmware
credential
service
dependencies.
Every Connectivity Module Adds a Supply-Chain Security Surface.
Ethernet
A wired connector may provide direct network access.
A Cable Is Not Authentication.
USB
USB may expose:
debugging
file transfer
update
network interfaces.
One Connector Can Expose Several Trust Boundaries.
USB Production Mode
Development USB functionality should be reviewed before final release.
Developer Convenience Should Not Accidentally Ship as Product Authority.
UART Console
Serial console can be invaluable for engineering.
Production question:
Should It Still Provide a Shell?
100 — JTAG / SWD
Debug interfaces provide extraordinary control.
Debug Access Is a Security Architecture Decision.
101 — Debug Policy
Possible states can include:
Development Open
Manufacturing Controlled
Production Restricted
depending on platform/product.
Debug Lifecycle Should Follow Product Lifecycle.
102 — Debug Lock
If debug is locked:
Can Authorized Engineering Still Diagnose Field Failures?
Security and serviceability must be balanced.
103 — Authenticated Debug
Some platforms can support controlled authorization of privileged debug access.
“Open Forever” and “Permanently Blind” Are Not the Only Two Choices.
104 — Boot Pins
Hardware boot straps can create alternate execution paths.
Secure Boot Review Must Include Physical Boot Configuration.
105 — External Flash
If firmware lives in external memory:
Can an attacker replace or modify it?
Secure boot architecture should not depend only on physical obscurity.
106 — Flash Confidentiality
If proprietary code extraction is a concern:
Readout protection and/or encryption may be relevant.
But:
Confidentiality Is Separate From Execution Authenticity.
107 — Readout Protection
MCUs may offer mechanisms limiting debug/read access.
Security Configuration Should Be Verified After Manufacturing.
108 — Secure Configuration Fuse
One-time settings can be powerful.
They can also be irreversible.
Permanent Security State Requires Production Discipline.
109 — Manufacturing Provisioning
Factory processes may program:
Firmware
Keys
Certificates
Debug Policy
Serial Identity
Manufacturing Creates the Initial Cybersecurity State.
110 — Factory Access Control
Who can:
provision
sign
read credentials?
Manufacturing Personnel and Systems Also Have Privileges.
111 — Shared Manufacturing Secret
Avoid architectures where one leaked production secret compromises every unit.
Limit Blast Radius at the Factory Too.
112 — Device-Unique Provisioning
Each device can receive unique identity material where architecture calls for it.
Production Cybersecurity Should Scale Per Unit.
113 — Provisioning Traceability
Record:
without unnecessarily exposing secret material.
Security State Should Be Traceable — Secrets Should Not Be.
114 — Factory Verification
After provisioning:
Verify Security Configuration.
Don't assume a fuse/setting was applied merely because a command was sent.
115 — Production Escape Risk
A device leaving production with:
development key
open debug
can create long-term exposure.
Security Is an End-of-Line Requirement.
116 — Supply-Chain Security
Product software incorporates:
libraries
bootloaders
vendor BSPs
drivers.
Your Product Inherits Dependencies' Vulnerabilities.
117 — Software Inventory
Know:
What Software Ships.
This is where:
becomes important.
118 — SBOM
A Software Bill of Materials can identify:
component
version
supplier
relationship
according to chosen framework/process.
Software Traceability Enables Vulnerability Traceability.
119 — SBOM Is Not Vulnerability Management
A list of dependencies is useful.
But:
Someone Still Needs to Monitor and Act.
120 — Dependency Version
“OpenSSL included” is not enough.
Which Version?
Which patches?
Which configuration?
121 — Transitive Dependency
Your application may not directly depend on vulnerable component X.
A library may.
Dependencies Have Dependencies.
122 — Vendor BSP
Vendor BSP can contain:
kernel
drivers
binary firmware.
SoC Selection Is Cybersecurity Supply-Chain Selection.
123 — Binary Blobs
Closed-source dependencies may limit:
internal review
patch autonomy.
Supplier Support Lifetime Becomes Product Security Lifetime.
124 — Component Lifecycle
Hardware components also contain firmware.
Examples:
modem
SSD controller.
One Product Can Contain Many Independently Patchable Computers.
125 — Secure Software Development Lifecycle
Security should exist across:
Security Is an SDLC Property.
126 — NIST SSDF
NIST SP 800-218 Version 1.1 remains the current finalized SSDF publication. It defines a core set of high-level secure software-development practices intended to reduce vulnerabilities, mitigate their impact and address root causes across development processes. NIST's Version 1.2 work is currently still a draft revision.
Secure Development Should Be Repeatable Process — Not Individual Heroics.
127 — IEC 62443-4-1
For industrial product manufacturers, IEC 62443-4-1 explicitly addresses:
security requirements
secure design
secure implementation
verification/validation
defect management
patch management
end of life.
Product Security Has a Lifecycle Standard.
128 — Security Requirements
A requirement should be measurable.
Weak:
Product shall be secure.
Better:
Only authenticated and authorized entities may perform defined privileged operations.
Security Requirements Should Be Verifiable.
129 — Security Architecture Review
Before implementation:
review:
Assets
Trust Boundaries
Interfaces
Privilege
Data Flow
Recovery
Architecture Bugs Are Cheaper to Fix Before Code Exists.
130 — Secure Coding
Coding guidelines should address relevant classes such as:
memory safety
input validation
error handling.
Secure Design Can Still Be Destroyed by Unsafe Implementation.
131 — Compiler Warnings
Treat serious warnings appropriately.
The Compiler Is an Early Defect Detector.
132 — Static Analysis
Static analysis can identify selected bug patterns before runtime.
Find Defects Without Waiting for Test Inputs.
133 — Dynamic Analysis
Runtime testing can expose:
memory
concurrency
input-handling
problems.
Some Defects Exist Only During Execution.
134 — Code Review
Security-sensitive areas deserve deliberate peer review.
Examples:
authentication
update
key handling
parsers.
Critical Code Deserves Critical Attention.
135 — Dependency Scanning
Track known issues in third-party components.
Vulnerability Intelligence Should Reach the Product Team.
136 — Secrets Scanning
Prevent:
passwords
signing keys
tokens
from entering repositories.
Version Control Is Not Secret Storage.
137 — CI Security
Automated build pipelines have privileged access to:
code
artifacts
sometimes credentials.
Compromised CI Can Compromise Every Future Device.
138 — Build Integrity
Know which:
Source
Toolchain
Configuration
created shipping software.
Release Provenance Is Security Evidence.
139 — Reproducible Builds Direction
Where appropriate, reproducibility can help verify that controlled source/build inputs correspond to shipped artifacts.
A Binary Should Not Be a Mystery.
140 — Signing Pipeline
Firmware signing should have:
controlled identity
limited permissions
audit trail.
Release Authorization Is a Security Boundary.
141 — Developer ≠ Signing Authority
Not every engineer who can compile code must automatically have permission to authorize production firmware.
Separate Creation From Authorization.
142 — Development Environment
Development units may intentionally allow:
debug
unsigned test software
where controlled.
Development Security Policy and Production Security Policy Can Differ.
143 — Production Build
Production should remove unnecessary:
test credentials
debug services
engineering shortcuts.
Development Convenience Should Have a Defined Exit.
144 — Hard-Coded Credentials
Hard-coded shared credentials create severe lifecycle problems.
CISA's 2025 Product Security Bad Practices guidance specifically identifies hard-coded/default credential patterns among practices manufacturers should move away from.
Secrets in Source Code Become Secrets in Every Product.
145 — Security Logging
Products need enough logs to answer:
What Happened?
146 — Security Events
Potential event classes include:
authentication failure
update rejection
security-policy change
credential problem.
Security State Should Leave Evidence.
147 — Don't Log Secrets
Logs should not expose:
private keys
passwords
sensitive tokens.
Observability Should Not Create a New Data Leak.
148 — Log Integrity
If logs support investigation:
Can an attacker simply erase or modify them?
The answer depends on architecture/risk.
149 — Time
Security logs need meaningful timestamps.
Time Synchronization Can Become Forensic Infrastructure.
150 — Security State Awareness
NISTIR 8259A includes cybersecurity state awareness among its core IoT device cybersecurity capabilities.
The Product Should Be Able to Communicate Important Security State.
151 — Detection
Protection eventually fails somewhere.
Therefore products may need ways to identify:
abnormal state
integrity failure
repeated authentication problems
depending on risk.
Cyber Resilience Includes Detection.
152 — Response
What happens when abnormal activity is detected?
Security Alarm Without Response Policy Is Incomplete.
153 — Recovery
After security failure:
Return to a Known, Authorized State.
Again:
154 — Fail Secure
When security subsystem fails:
avoid automatically defaulting into:
everyone gets admin access.
Failure State Should Preserve Appropriate Security Properties.
155 — But Availability Matters
Overly aggressive security can also make product unusable.
Security Design Balances Confidentiality, Integrity and Availability.
156 — Denial of Service
Resource exhaustion can affect:
storage
network.
Product Availability Should Be Designed Under Abnormal Load.
157 — Watch Resource Limits
A malformed input should not cause:
infinite allocation
infinite loop
unlimited logging.
Defensive Resource Management Is Cybersecurity.
158 — Secure Communications
Transport security can protect:
Device ↔ Cloud
App ↔ Device
Gateway ↔ Device
depending on architecture.
Protect the Real Trust Boundary.
159 — Encryption Is Not Authorization
A TLS connection can be perfectly encrypted while the authenticated user still lacks permission for:
The Requested Action.
160 — Endpoint Authentication
Both ends should understand:
Who Is the Peer?
161 — Certificate Validation
Don't merely ask:
Did TLS connect?
Ask:
Did We Authenticate the Intended Endpoint?
162 — Credential Pinning / Trust Store
Trust configuration should be designed for:
security
future rotation.
Hard-Wiring Today's Certificate Forever Can Create Tomorrow's Maintenance Problem.
163 — Protocol Security
Page 30 established:
The Wire Carries Bits. The Protocol Carries Meaning.
Here we add:
The Security Architecture Determines Who Is Allowed to Give That Meaning Authority.
164 — Command Authentication
Commands that change product behavior deserve stronger scrutiny than background telemetry.
Remote Command Is Remote Authority.
165 — Command Authorization
User may have permission to:
but not:
Actuate.
Every Sensitive Operation Needs Explicit Authorization.
166 — Command Replay
Previously valid command may no longer be appropriate.
Security Needs Freshness.
167 — Command Audit
For high-value remote operations:
Who Sent It?
When?
To Which Device?
168 — Cloud Security
A secure device connected to an insecure cloud is:
Not a Secure Product System.
169 — Cloud Identity
Backend services need controlled:
service accounts
permissions.
Machine Privilege Exists on Both Sides of the Internet.
170 — Multi-Tenant Isolation
Customer A should not access:
Customer B's Devices.
171 — Tenant Authorization
Every backend request should preserve:
Ownership Context.
172 — Cloud Secrets
Keep:
signing keys
in appropriate secret-management architecture.
Cloud Configuration Is Product Security.
173 — Cloud Logging
Critical administrative operations need traceability.
Fleet Security Requires Fleet Auditability.
174 — OTA Security
Firmware updates are among the most privileged remote operations.
OTA Pipeline Is Part of Cybersecurity Architecture.
175 — Signed Update
Device should authenticate software independent of:
Transport.
176 — OTA Targeting
Even a good image can be dangerous when sent to:
Wrong Hardware.
Cybersecurity Includes Configuration Integrity.
177 — Update Authorization
Who may launch:
100,000-device update?
Fleet Permission Is High-Impact Authority.
178 — Canary Deployment
Cybersecurity patch urgency still does not eliminate:
Product Validation.
Securely deploying broken software is still failure.
179 — Incident Update
An emergency patch process should be:
but:
Controlled.
Cybersecurity Response Needs Pre-Built Release Infrastructure.
180 — Vulnerability Management
Security does not end at product release.
A mature lifecycle is:
Vulnerability Management Is Product Maintenance.
181 — CVE Is Not Risk by Itself
A vulnerability in an unused package may differ greatly from:
remotely reachable
privileged component.
Vulnerability Severity Must Be Interpreted in Product Context.
182 — Exploitability
Ask defensively:
Is the affected component present?
Is the vulnerable functionality enabled?
Is it reachable?
What privilege could be gained?
Vulnerability Assessment Should Follow Actual Product Architecture.
183 — Patch Priority
Critical reachable issue may require urgent response.
Patch Speed Should Follow Risk.
184 — Known Exploited Vulnerabilities
Known active exploitation increases urgency.
CISA's product-security guidance specifically emphasizes timely handling of known exploited vulnerabilities for relevant manufacturers.
Real Exploitation Changes Risk Prioritization.
185 — Patch Testing
Security fix can create:
regression
compatibility issue.
Security Patch Still Needs Engineering Validation.
186 — Patch Distribution
Patch exists.
But:
Did Deployed Products Actually Receive It?
187 — Fleet Exposure
A fleet-management system should help answer:
Which units are still vulnerable?
Vulnerability Management Needs Device Inventory.
188 — Vulnerability Disclosure Policy
Customers and researchers need a defined channel to report:
Potential Security Problems.
189 — Coordinated Vulnerability Disclosure
A mature process handles:
Vulnerability Reports Are Engineering Inputs.
190 — Security Contact
Publish a clear:
security contact
process
appropriate to the business.
Don't Make Researchers Guess Where to Report a Serious Issue.
191 — PSIRT Direction
Larger product companies often operate a Product Security Incident Response Team function.
365PCB should only claim this if a real operational process exists.
Process Name Matters Less Than Real Responsibility.
192 — Security Advisory
When necessary, customers may require information on:
affected versions
mitigation
fixed version.
Transparency Is Part of Security Support.
193 — Support Period
Customers need to know:
How Long Security Support Exists.
This is increasingly important under modern product-security frameworks.
194 — End of Security Support
A product eventually reaches EOL.
Unmaintained Connected Products Do Not Magically Stop Having Vulnerabilities.
195 — EOL Strategy
Possible considerations include:
final update
migration path
credential retirement.
Security Lifecycle Includes Product Retirement.
196 — NIST IR 8259 Rev.1
The 2026 revision emphasizes the full IoT product, and broadens manufacturer considerations around cybersecurity communication, maintenance, support and end-of-life across pre-market and post-market lifecycle activities.
Product Security Is No Longer Only Pre-Launch Engineering.
197 — Consumer IoT Baseline
ETSI EN 303 645 V3.1.3 is designed as an outcome-focused baseline for consumer IoT security and includes provisions around update mechanisms and timely security updates.
IoT Security Has Matured Into Product Engineering Baselines.
198 — Industrial Cybersecurity
For industrial products, security requirements may need alignment with the IEC 62443 ecosystem.
Consumer IoT and Industrial Control Have Different Risk Models.
199 — IEC 62443 Foundational Requirements
IEC 62443-4-2 organizes component requirements around:
Resource Availability.
This is a very useful architecture checklist.
200 — Security Levels
IEC 62443 uses security-level concepts in its IACS architecture.
Don't Claim an SL Rating Without the Required Scope, process and evidence.
365PCB should say:
or:
certification-readiness support
unless a formal certification actually exists.
201 — CRA
Europe is changing the business importance of product cybersecurity.
The Cyber Resilience Act applies to broad categories of products with digital elements subject to its scope and defines essential cybersecurity requirements spanning product characteristics and vulnerability handling.
Cybersecurity Can Become Market-Access Engineering.
202 — CRA Dates
For planning:
Chapter IV provisions apply.
Article 14 applies.
the Regulation generally applies.
As of August 30, 2026, that means the Article 14 milestone is imminent.
203 — CRA Risk Assessment
CRA Annex I explicitly ties product cybersecurity to:
Risk.
Not simply:
checklist compliance.
Security Controls Should Be Justified by Product Risk.
204 — Secure by Default
CRA Annex I explicitly references secure-by-default configuration where applicable.
Secure Defaults Are Moving From Advice Toward Regulatory Expectation.
205 — Vulnerability Handling
Modern product-security regimes increasingly expect manufacturers to maintain security after market launch.
The Product Team Needs a Post-Sale Cybersecurity Function.
206 — Security Documentation
Depending on market/product, documentation can include:
Threat Model
Security Requirements
Architecture
SBOM
Update Policy
Support Period
Risk Analysis
Security Evidence Is Part of Product Documentation.
207 — Certification ≠ Security
A certificate can demonstrate conformance to defined requirements/scope.
But:
208 — Security ≠ Compliance
Compliance asks:
Did we meet a defined requirement?
Security asks:
Is the risk sufficiently controlled in the actual product?
Good Engineering Needs Both Where Applicable.
209 — Security Verification
A product-security requirement should have:
A Verification Method.
210 — Security Unit Tests
Security-sensitive code can have tests for:
authorization
parser rejection
update validation.
Security Requirements Should Enter the Test Suite.
211 — Negative Testing
Don't only test:
correct password accepted.
Also test:
incorrect/expired/unauthorized input rejected.
Rejection Behavior Is Security Behavior.
212 — Boundary Testing
Parsers should be tested around:
minimum
maximum
invalid length.
Security Bugs Often Live at Boundaries.
213 — Fuzz Testing
In controlled development, automated malformed-input testing can help identify parser robustness issues.
Test Unexpected Input Before the Field Provides It.
214 — Protocol Fuzzing
Applicable to:
file formats
network protocols
command parsers
where appropriate.
A Parser Should Fail Predictably.
215 — Static Security Analysis
Automated tooling can detect selected vulnerability classes before execution.
Shift Defect Discovery Earlier.
216 — Dynamic Security Testing
Runtime behavior can reveal issues static inspection misses.
Different Testing Methods Find Different Defects.
217 — Penetration Testing
Authorized product security assessment can test whether assumptions hold against realistic misuse scenarios.
Penetration Testing Validates Architecture — It Does Not Replace Architecture.
218 — Test Scope
Define:
interfaces
software version
hardware version
assumptions.
Security Test Results Are Scope-Specific.
219 — Re-Test
After fixing a security finding:
Verify the Fix.
And verify relevant regressions.
220 — Red Team vs Product Testing
For highly mature programs, deeper adversarial assessment may add value.
But:
Security Maturity Should Grow From Requirements and Architecture First.
221 — Hardware Security Testing
Product security review may include, depending on scope:
debug interface state
boot configuration
external memory protection
secure provisioning verification.
PCB Is Part of the Security Boundary.
222 — Physical Access
Threat model should define:
Does the Attacker Have the Device in Hand?
This dramatically changes assumptions.
223 — Tamper Resistance
Physical tamper controls may be relevant for specific high-value products.
But:
Don't Add Expensive Physical Security Without a Defined Threat.
224 — Tamper Evidence vs Tamper Resistance
These are different.
Shows intervention occurred.
Attempts to make intervention harder.
Define the Required Property.
225 — Side-Channel Resistance
Certain high-security cryptographic devices may need specialist analysis.
This Is an Advanced, Platform-Specific Domain.
365PCB should only advertise such capability if specialist expertise and validation really exist.
226 — Fault Resistance
Similarly, high-assurance cryptographic hardware may require protection against abnormal physical conditions.
Do Not Claim Advanced Hardware-Security Resistance Without Evidence.
227 — Product Security Architecture Should Be Calibrated
A $10 consumer sensor and high-value industrial controller should not necessarily have identical security architectures.
Security Cost Should Follow Risk and Product Value.
228 — Security Budget
Cybersecurity consumes:
Flash
RAM
CPU
Boot Time
Engineering Time
Cloud Cost
Security Has Resource Requirements.
229 — Security Performance
TLS handshakes, signatures and encryption consume compute.
Security Performance Should Be Engineered — Not Removed.
230 — Hardware Crypto
MCUs/SoCs may include cryptographic acceleration.
Platform Selection Can Reduce Security Overhead.
231 — Power
Battery IoT security operations consume energy.
Cybersecurity Can Become a Power-Budget Item.
232 — Secure Element BOM Cost
Security hardware adds:
cost
board area
supply-chain dependency.
Security Architecture Is Also BOM Engineering.
233 — Reliability
A secure element failure can prevent product authentication.
Security Components Need Reliability Engineering Too.
234 — Availability vs Strict Lockdown
If security mechanism permanently locks the customer out after a benign fault:
The Product May Be Secure but Unusable.
Engineering must preserve recoverability.
235 — Account Recovery
User credential loss needs a controlled recovery path.
Recovery Should Restore Authorized Access Without Creating a Universal Backdoor.
236 — No Universal Service Password
A universal hidden service credential is attractive operationally.
But:
Fleet-Wide Master Credentials Create Fleet-Wide Risk.
237 — Service Technician Identity
Where remote/privileged service is required:
Authenticate the Technician — Not Merely the Tool.
238 — Time-Limited Privilege
Temporary service authorization can reduce long-lived access.
Privilege Can Have Expiration.
239 — Manufacturing Service Mode
Production needs access to test functions.
Shipping customer devices usually should not expose the same authority indefinitely.
Factory Mode Needs an Exit.
240 — Security State Machine
A product may have states such as:
Security Permissions Can Follow Lifecycle State.
241 — Product Ownership Transfer
If the device changes owners:
What Happens to Previous Credentials?
242 — Factory Reset
Factory reset must define separately:
user data
network credentials
device identity
manufacturer trust.
Reset Does Not Mean Destroy the Device's Root Identity.
243 — Decommissioning
End-of-life should remove or invalidate:
user identity
cloud authorization
as appropriate.
Retirement Is a Cybersecurity State Transition.
244 — Privacy
Security protects data.
Privacy asks:
Should We Collect This Data at All?
245 — Data Minimization
Collect only information required for the product/business requirement.
Data You Never Collect Cannot Become Your Data Breach.
246 — Local Processing
Edge AI can reduce transmission of raw:
audio
video
sensor
data.
Edge Architecture Can Be a Privacy Architecture.
247 — Data Retention
Define:
How long is this data needed?
Infinite Retention Is Not Automatically Valuable.
248 — Security and Privacy Architecture
A secure product can still violate privacy expectations.
Confidentiality Does Not Answer Data-Use Questions.
249 — Security Risk Register
Maintain identified:
Threat
Asset
Risk
Control
Residual Risk
Verification
Cybersecurity Should Be Traceable Like Other Engineering Risk.
250 — Security Requirement Traceability
For each requirement:
Security Should Have an Engineering Digital Thread.
251 — Security Design Review
Review at major gates:
Security Should Not Be One Final Audit.
252 — EVT Security
EVT asks:
Does the Intended Security Architecture Work on the Real Hardware?
Validate:
secure boot
identity
storage
interfaces
debug policy.
253 — EVT Is for Observability
Development systems need sufficient diagnostic visibility.
Don't Lock the Hardware So Early That Engineering Becomes Blind Without a Planned Debug Strategy.
254 — DVT Security
DVT asks:
Does the Final Product Configuration Resist the Defined Threats and Recover Correctly?
Validate:
authentication
permissions
update
interface restrictions
fault/recovery behavior.
255 — DVT Negative Tests
Try:
unauthorized software
unauthorized credentials
malformed inputs
in controlled validation.
Security Requirements Need Failure-Path Evidence.
256 — PVT Security
PVT asks:
Can Manufacturing Create the Intended Security State Every Time?
257 — Production Security Audit
Verify selected production units for:
Correct Boot Policy
Correct Firmware
Correct Device Identity
Correct Debug State
Security Manufacturing Needs Statistical Confidence Too.
258 — Security Traceability
Production can associate:
Security State Becomes Part of Product Configuration.
259 — Field Security
After shipment:
monitor:
software versions
vulnerability status
credential state
update coverage.
Field Security Is Fleet Engineering.
260 — Security Telemetry
Useful fleet security information may include:
secure-boot result
firmware version
update status
abnormal authentication count
depending on architecture/privacy.
Security Can Be Observable Without Exposing Secrets.
261 — Hardware Cohort Analysis
Suppose security instability occurs only on:
Hardware Rev A.
Cybersecurity Symptoms Can Have Hardware Dependencies.
262 — Security + Manufacturing
Imagine:
device authentication failures correlate with:
Secure Element Lot X.
Now cybersecurity telemetry becomes:
Manufacturing Reliability Evidence.
263 — Firmware + Hardware
New cryptographic operation increases:
current demand.
Marginal power supply starts resetting.
A Security Feature Can Expose a Hardware Margin Problem.
264 — Security + Thermal
Continuous encrypted communication increases:
heat.
Cybersecurity Has Physical-System Consequences.
265 — Security + RF / Connectivity
Aggressive reconnect/authentication cycles can affect:
power
network load.
Security Behavior Must Be Tested in the Complete Product.
266 — Security Root-Cause Engineering
When product reports:
TLS authentication failed,
the root cause might be:
Security Failure Can Be Cross-Disciplinary.
267 — This Is Where 365PCB Can Become Different
A cybersecurity consultancy may see:
Security Log.
A firmware team may see:
Authentication Failure.
A manufacturing team may see:
Device Passed EOL Test.
An integrated ODM can correlate:
Cybersecurity Can Become Whole-Product Engineering.
268 — Secure Product Digital Thread
A powerful future architecture is:
Security Evidence Can Follow the Product Through Its Entire Life.
269 — Product Security Improvement Loop
Every Security Failure Should Improve the Development System.
270 — Eliminate Vulnerability Classes
This connects strongly to CISA's Secure by Design philosophy.
Don't only patch:
Buffer Overflow #127.
Ask:
Why Does This Class of Defect Keep Appearing?
CISA's memory-safety guidance explicitly promotes reducing whole vulnerability classes rather than endlessly treating individual defects.
Fix the System That Creates the Bug.
271 — World-Class Product Cybersecurity
At the highest level:
That is the difference between:
and:
Engineering Product Cybersecurity.
Depending on actual project scope, a 365PCB ODM cybersecurity program may include:
Product Cybersecurity Requirements
Cybersecurity Risk Assessment Inputs
Threat Modeling
Asset Identification
Trust-Boundary Analysis
Attack-Surface Review
Data-Flow Security Review
Security Architecture
Security Requirement Traceability
Hardware Security Architecture Inputs
Hardware Root-of-Trust Inputs
Secure Element Integration Inputs
TPM Integration Inputs
TEE / TrustZone Architecture Inputs
MPU / MMU Isolation Inputs
Secure Boot Architecture
Secure Firmware Update Inputs
Anti-Rollback Inputs
Recovery Architecture
Device Identity Architecture
Device Certificate Inputs
PKI Architecture Inputs
Key-Generation Architecture
Key-Provisioning Inputs
Secure Key Storage Inputs
Key Rotation
Key Revocation
Crypto-Agility Inputs
Authentication Architecture
Authorization Architecture
Role-Based Access Inputs
Least-Privilege Architecture
Session-Security Inputs
Replay-Protection Inputs
Secure Communication Architecture
TLS Integration Inputs
Secure Protocol Inputs
Secure Storage
Data-at-Rest Protection Inputs
Debug-Port Security
JTAG / SWD Production Policy
UART Console Security
USB Interface Security
Boot-Mode Security Inputs
Network Attack-Surface Review
Service-Minimization Review
Embedded Linux Hardening Inputs
Process Isolation
Linux Capabilities Inputs
SELinux / AppArmor Inputs
seccomp Inputs
Firmware Memory-Protection Inputs
Memory-Safety Strategy
Secure Coding Guidelines Inputs
Static Analysis Inputs
Dynamic Analysis Inputs
Secure Code Review
Parser Robustness Testing
Fuzz-Testing Inputs
Authentication Negative Testing
Authorization Negative Testing
Security Regression Tests
Dependency Inventory
Third-Party Component Review
SBOM Inputs
Vulnerability Monitoring Inputs
Secure Software Development Lifecycle
NIST SSDF Alignment Inputs
IEC 62443-4-1 Alignment Inputs
IEC 62443-4-2 Component Security Inputs
ETSI EN 303 645 Readiness Inputs
EU CRA Readiness Inputs
Secure-by-Design Review
Product-Security Documentation
Secure CI/CD Inputs
Build-Provenance Inputs
Firmware Signing Architecture
Artifact Integrity Inputs
Production / Development Key Separation
Secure Provisioning
Device-Unique Identity Provisioning
Production Security State Verification
Factory Test Security Controls
EOL Security Test
Security Configuration Traceability
Vulnerability Disclosure Process Inputs
Security Contact / Reporting Process Inputs
Vulnerability Triage
Patch Management Inputs
Security Advisory Inputs
Product Security Incident Response Inputs
Security Support-Lifecycle Planning
Security Update Coverage Inputs
Field Security Telemetry
Security Event Logging
Audit-Log Inputs
Fleet Security State Inputs
Credential-Rotation Inputs
Decommissioning Security Inputs
Product Ownership Transfer Inputs
Factory Reset Security Inputs
Authorized Security Assessment Support
Certification-Readiness Documentation Inputs
EVT Security Validation
DVT Security Validation
PVT Security Validation
Security Root-Cause Analysis
Hardware / Software Security Correlation
Security Lifecycle Maintenance
Product Cybersecurity Architecture Documentation
The actual engineering depth should follow:
Product Function + Threat Model + Connectivity + Data Sensitivity + Physical Access + Hardware Platform + Operating System + Cloud Architecture + Market + Product Lifetime.
You can begin with:
Product Architecture
Schematic
MCU / SoC
Embedded Linux / RTOS
Current Firmware
Cloud Architecture
Communication Protocol
Threat Model
Existing Security Requirements
Target Market
OTA Architecture
Manufacturing Provisioning Process
Existing Security Findings
or simply:
Tell Us What the Product Must Protect, Who Should Be Allowed to Control It, and What Must Happen When Trust Is Lost.
365PCB can help translate:
Don't Just Add Encryption.
Identify the Assets.
Define the Threats.
Map the Trust Boundaries.
Reduce the Attack Surface.
Anchor the Root of Trust.
Authenticate the Software.
Protect the Keys.
Authenticate the Device.
Control the Privileges.
Isolate Critical Software.
Validate Every External Input.
Protect the Communication.
Secure the Debug Interfaces.
Build Software Securely.
Know What Components You Ship.
Keep an SBOM.
Patch Vulnerabilities.
Provision Security Correctly in Manufacturing.
Test Unauthorized Behavior.
Secure the OTA Path.
Detect Abnormal Conditions.
Recover to a Trusted State.
Rotate Credentials.
Support Security for the Product Lifetime.
365PCB Product Cybersecurity Design connects:
Hardware + PCB + Firmware + RTOS + Linux + Connectivity + Cloud + Cryptography + Manufacturing + OTA + Vulnerability Management
into one coordinated cybersecurity engineering process.
Product Cybersecurity Is Not a Feature Added to the Product.
It Is a Property Created by the Architecture, Development Process, Manufacturing Process, and Lifecycle of the Product.
And:
Security Begins Before the First Line of Firmware — and Continues After the Last Product Ships.
[Discuss Your Product Security Architecture]
[Submit Your Cybersecurity Requirements]
[Request a Product Cybersecurity Architecture Review]
English
