ASSESSMENT METHOD

For every step: a named input, reviewer, and output.

Your team owns the product facts and risk decision. Q-Forge structures the evidence, exposes what is missing, and turns the review into an actionable roadmap.

Six review gates from scope to roadmap.

Missing evidence creates a visible investigation action. It never becomes an optimistic default.

01

Define the decision boundary

Customer input: Product family, variants, baselines, cohorts, markets, owners, obligations, horizon, and deadline.

Q-Forge produces: A written scope, exclusions, ownership map, source register, and coverage gaps.

Reviewer: Customer product owner and security lead.

Stage output: Accepted scope and success criteria.

02

Map cryptographic uses

Customer input: Authorized records for identity, communications, secure boot, signing, provisioning, certificates, libraries, and suppliers.

Q-Forge produces: A variant-linked inventory with source and confidence for every recorded use.

Reviewer: Product security and implementation owners.

Stage output: Reviewed inventory and explicit gap list.

03

Establish product constraints

Customer input: Hardware resources, power, timing, network, boot, update, secure component, lifecycle, certification, and supplier constraints.

Q-Forge produces: A constraint profile linked to each relevant hardware and firmware variant.

Reviewer: Embedded, systems, lifecycle, and compliance specialists.

Stage output: Approved feasibility boundary.

04

Compare candidate designs

Customer input: Architecture objectives, supported dependencies, transition preferences, threat assumptions, and acceptable operational tradeoffs.

Q-Forge produces: Named candidates with exact profiles, assumptions, compatibility questions, rejected options, and acceptance criteria.

Reviewer: Security architect, embedded lead, and affected suppliers.

Stage output: Agreed candidate and test plan.

05

Record and grade evidence

Customer input: Authorized test results, supplier material, build and target context, or approved access to qualified testing resources.

Q-Forge produces: An evidence register showing target relevance, method, source, date, result, limitations, and grade A–D.

Reviewer: Qualified technical reviewer. DeviceLab records results; it does not run lab tests by itself.

Stage output: Reviewed evidence and unresolved-question plan.

06

Approve the disposition

Customer input: Decision authority, risk tolerance, budget and lifecycle context, implementation ownership, and deadline.

Q-Forge produces: An explainable suggestion, alternatives, rationale, residual risks, triggers, and dated roadmap.

Reviewer: Named customer decision owner and required engineering, security, safety, legal, or compliance authorities.

Stage output: Upgrade, redesign, replace, retire, or investigate decision plus roadmap.

Know what was measured and where.

Grade C or D evidence can guide investigation. It cannot be presented as production validation.

A

Measured on representative production hardware and software with reproducible artifacts.

B

Measured on an engineering-equivalent target with documented differences.

C

Supplier, library, or reference-platform evidence not reproduced on the target.

D

Assumption, estimate, or unverified stakeholder statement.

The software suggests. Named authorities approve.

A DeviceLab status is decision support, not a security guarantee or certification.

  1. Product and security owners accept inventory coverage
  2. Embedded or systems engineering accepts the constraint profile
  3. A qualified reviewer accepts the test method and evidence grade
  4. Architecture reviews alternatives and residual risk
  5. The customer decision owner approves lifecycle action

Apply the method to one device family.

Create your workspace and begin immediately with synthetic data or an approved product boundary.