The short answer

A useful architecture review does more than confirm that a diagram contains devices, a broker, storage, and an application. It makes identity, degraded behavior, data contracts, tenant boundaries, release safety, observability, restoration, and business ownership explicit. This checklist gives a cross-functional team ten prompts for that conversation.

Checking every item does not certify an architecture. A check means the team has reviewed the control and can point to current evidence. If the evidence is a future ticket, an untested assumption, or one person’s memory, leave the item open and name an owner.

What each control asks

The ten controls cover distinct system boundaries:

  1. Managed identity: every device can be authenticated, rotated, revoked, and traced without treating a shared secret as identity.
  2. Offline behavior: product and operations teams agree what the device does when connectivity, time, storage, or dependencies degrade.
  3. Versioned message contracts: producers and consumers can evolve without silently reinterpreting the same payload.
  4. Tenant isolation: identity, authorization, topics, storage, caches, logs, and support tooling preserve the boundary.
  5. Data retention: raw telemetry and durable business events have separate purposes, owners, and retention policies.
  6. Safe OTA: releases use staged cohorts, compatibility gates, health signals, pause criteria, and tested recovery.
  7. Recovery observability: operators can see backlog, error rate, saturation, and time to restore service.
  8. Secret lifecycle: credentials can be issued, rotated, revoked, audited, and recovered at fleet scale.
  9. Failure restoration: the design has survived a representative outage exercise rather than only a happy-path load test.
  10. Business closure: alerts and automated actions end with an accountable owner and an observable outcome.

How the score works

The percentage is simply:

checked controls ÷ 10 × 100

All controls are weighted equally. That is intentional: the score reports review completion, not risk severity. One missing device-identity control can be more consequential than several completed documentation controls. Use the result as an agenda and evidence index, never as an approval threshold.

Worked review

Imagine a team marks identity, message contracts, tenant isolation, retention, secret lifecycle, and business closure as complete. The result is 60% evidenced: six controls checked and four still open. The missing items are offline behavior, OTA recovery, recovery observability, and restoration testing.

The productive next step is not to chase 100% mechanically. The team should attach an owner and evidence requirement to each gap. Firmware may own a documented offline state machine; release engineering may own rollback evidence; operations may define recovery dashboards; and the platform team may run a reconnect and backlog-drain exercise. The next review should examine those artifacts, not merely recheck the boxes.

Limits of the checklist

This is not a threat model, safety case, privacy assessment, regulatory audit, detailed design review, or penetration test. It does not account for product-specific hazards, regional duties, radio certification, manufacturing controls, physical access, supply-chain risk, or organizational capability. Equal weighting means the percentage must not be compared across products or used as a maturity benchmark.

Adapt the evidence to the system. A battery sensor, industrial gateway, connected vehicle, and medical device require very different depth even when the control labels look similar.

Privacy and portable results

The checklist runs entirely in the page. Checked states are encoded as simple item flags in the current URL so a review state can be reopened or shared. The URL contains no notes, evidence, credentials, or uploaded files because the tool does not collect them. Still, the pattern of completed controls may be sensitive in some organizations; share the link only with the intended audience.

Copy and JSON, CSV, or Markdown export all happen locally. Nothing is sent to IoT 01.

FAQ

Does 100% mean the architecture is ready?

No. It means every prompt was marked complete. Approval requires credible evidence, product-specific risk analysis, and at least one realistic failure exercise.

Who should attend the review?

Include product, firmware, hardware where relevant, platform, security, data, operations, support, and the owner of the business process affected by device behavior.

Should every team use the same evidence?

No. Keep the questions stable enough to compare review rounds, but make evidence proportional to the product’s hazards, scale, lifecycle, and regulatory context.

Read Designing the device operations loop to connect telemetry, decisions, actions, acknowledgements, and owned outcomes across the architecture.