Trust boundaries and isolation: which component can access which data and functions?
07 / ARCHITECTURE REVIEW
Product Security Architecture Review
Security design for embedded systems, software and platforms
We examine whether your product security architecture holds under the agreed attacker assumptions. Trust boundaries, identities, privileges, keys and recovery are considered together, before implementation or when making fundamental changes.
Review scope
Review security decisions in context.
Identity and authorization: where are access decisions made and where are they enforced?
Compromise: how far do the privileges of a compromised device, client, service or administrator extend?
Keys and signatures: who creates, uses, rotates and revokes keys?
Boot, updates and recovery: which alternative paths can bypass the intended checks?
Failure and recovery: what happens after an outage, lost key or state reset?
Illustrative review questions
From devices to standalone platforms.
Embedded system
Boot and recovery must enforce the same security rules. We examine how the boot ROM, bootloader, firmware, secure element and update service interact, and which privileges remain after a compromise.
Software platform
A compromised customer account must not give access to other customers through a remote management platform. We examine tenant isolation, administrative privileges and authorization between the platform and managed systems.
Cryptographic application
Encryption protects data only within its assumptions. We examine who can access keys and plaintext, and whether account recovery or key rotation bypasses the intended security boundaries.
Working with engineering
From an open question to a reasoned decision.
Define the security question
Which decision is pending and what protection must the product provide?
Understand the architecture
We discuss data flows, responsibilities, attacker positions and dependencies with your engineering team.
Examine the assumptions
We analyze abuse scenarios and failure cases. Where needed, we examine specific questions in code or prototypes within the agreed scope.
Record the decisions
You receive prioritized design changes and a test plan for questions that require implementation-level evidence.
Architecture documents, data flows, role models and existing security decisions are useful inputs. Complete documentation is not a prerequisite; we work through missing context with your team within the agreed scope. Implementation questions may require source code or prototypes.
Deliverables
Concrete changes and supporting reasoning.
- Assessment of the agreed security questions with supporting reasoning
- Documented attacker assumptions and relevant trust boundaries
- Concrete design changes with priorities and technical consequences
- A clear distinction between reviewed claims, open questions and residual risks
- A focused plan for code reviews, prototypes or later security testing
- A technical discussion of the results with your engineering team
When to commission a review
Before changes become costly.
- New product generation or platform
- Changes to identity, authorization or tenant isolation
- New provisioning, signing or update mechanism
- Decisions about secure elements, isolation or key management
- Remote access, administrative access or new integrations
- Recurring findings rooted in the design
Architecture review and security testing complement each other.
An architecture review examines the design and its assumptions. It does not establish that the eventual implementation enforces those rules. The results identify which code paths and system states need targeted testing next.
Which security decision are you facing?
Tell us about your product, its development stage and the open question. We will work with you to define the useful inputs and review scope.
NDA first if required.