Before choosing controls: threat modelling across device, application and cloud

A team has a device, mobile application, cloud service, and service tool. Each component passed its own tests. Yet the team still cannot say whether one customer’s device can submit data as another, whether a former technician retains access, or whether a correctly signed update fits a particular hardware revision. These questions cross component boundaries and need a shared model.

Threat modeling helps decide where controls belong and which tests should establish their effectiveness. Its output should extend beyond general statements such as encryption and strong passwords. We need a scenario, prerequisites, consequence, control, owner, and the risk that remains after the control is applied.

The example is fictional. It concerns measurement devices assigned to organizational accounts, with data access, configuration changes, and firmware updates. It is neither a BBest24 audit nor penetration-test results. Simple rules are checked locally; key protection, cryptographic correctness, and actual infrastructure behavior require separate verification.

Start with an unwanted decision

“Can another customer change my device’s settings?” is more useful to a product team than “Do we have TLS?” The latter asks about a mechanism. The former identifies a protected property and the effect of violating it. Choose mechanisms after understanding where the system decides identity, ownership, and permission.

Our scope protects device-account association, measurement integrity, authorized configuration changes, and execution of appropriate firmware. Availability matters too: rejecting every request may protect data while making the service unusable. We do not assume that general cybersecurity analysis replaces separate assessment of physical consequences in a critical application.

The OWASP Threat Modeling Cheat Sheet organizes work from system description through threats and responses to verification. Models should evolve with products. Adding offline local service therefore requires reviewing earlier assumptions even when the public API remains unchanged.

A useful scope also states what has not been assessed. We do not examine laboratory key extraction or the cloud provider’s entire organization in detail. This does not establish absence of risk. It states an analytical boundary to consider when deciding where to use the product and what work remains.

Draw flows and changes in trust

The user application sends requests to the service. The service stores account data and issues device commands. Devices publish telemetry. A technician’s tool has an additional local channel, while a publisher supplies update packages. Each flow carries information the recipient should not trust merely because it arrived from an expected network.

Trust boundaries need not match infrastructure boundaries. Two accounts in one database still require permission isolation. An authenticated user’s phone remains a source of alterable input. A company technician’s computer can be lost. A signed package has an identified origin but can still target another device model.

Include data stores and the identities permitted to access them. Our simplified diagram combines service and data, but a real queue, object store, or administrative panel may need separate detail. The level of detail should expose security decisions rather than reproduce every operating-system process.

For each flow, identify its initiator, recipient checks, and behavior when a check cannot be completed. “Validate the token” is incomplete without audience, scope, lifetime, and resource association. Likewise, “the device is ours” does not identify its customer or establish that it remains authorized.

S1: a device claims another identity

Device D-A has its own authenticated identity and belongs to account A. Its payload nevertheless declares deviceId = D-B or account B. If the service uses those fields without comparing them with the authenticated sender, a correctly established connection can deliver data into someone else’s resource. Channel encryption does not resolve that logic error.

Derive identity from trusted authentication results and check current ownership. Payload fields can provide additional information, but must not independently grant permission. Our model requires authenticated and declared device identities to agree, and registered ownership to match the requested account.

The negative test uses valid D-A credentials with a foreign identifier or account. Expect rejection before storage, with no side effect in account B. Examine logs, indexes, and events too: rejected input must not leave a foreign measurement in an auxiliary store even if the main table remains correct.

The risk of a stolen valid D-A key remains. Ownership binding does not automatically detect someone impersonating the correct device with its secret. Credential protection, revocation, unusual-behavior detection, and identity recovery are separate controls. They address another part of the scenario rather than invalidating the ownership rule.

Ownership transfer changes the answer

A device may be sold, replaced, or moved to another organization. Ownership is therefore not necessarily an immutable certificate property. Define transfer, proof of entitlement, and when the previous account loses access. Knowledge of a serial number alone should not permit takeover.

After transfer, examine existing sessions, queued commands, export links, and cached data. Revoking one endpoint’s access does not remove permissions elsewhere. Measurement history also needs an explicit policy: it may remain with the previous account, move with the device, or follow a separate procedure.

Test old and new contexts together. The previous owner attempts reads and control through an existing session, the new owner performs allowed actions, and the device publishes during the transition. Establish expected behavior before implementation, especially for queued messages whose authorization context may have changed.

S2: a former technician retains a token

A technician obtained service access to account A. That permission is revoked, but their computer retains a cryptographically valid token. A service checking only signature and expiry may continue accepting actions. Identity was authenticated, but current permission no longer exists.

The OWASP Authorization Cheat Sheet recommends checking permissions on every request, denying by default, and granting least privilege. Our example checks technician activity, account, role, and authorization generation. A token carrying an earlier generation is rejected after the current state changes.

This is one possible mechanism, not a universal session design. Short sessions, introspection, or revocation lists are alternatives. Know the maximum revocation delay and behavior when the permission source is unavailable. Cached decisions must have an explicit effect on that delay.

The negative test retains an issued token, revokes permission, and repeats an operation on the same device. Expect denial and no configuration change. Repeat for an active connection, session refresh, and retrieval of an earlier result. Removing a UI button does not test server-side enforcement.

Offline service reverses some assumptions

A service tool may need to operate without connectivity. The device cannot immediately learn a new revocation decision. Unlimited offline operation and immediate global revocation cannot both be promised without another communication path. This architectural limitation belongs in the product decision.

One option limits local permission scope and lifetime, binds it to a device, and requires renewal after expiry. However, clock behavior, restart, and clock rollback then become part of the model. If the device cannot reliably enforce lifetime, a “valid for one hour” field does not solve the problem.

We do not implement that protocol here. The map leaves bounded offline access as a risk requiring a separate decision and evidence. Depending on the product, offline access might be read-only diagnostics, require physical presence, or exclude configuration changes entirely. Choose based on misuse consequences and the actual service workflow.

S3: a valid signature on the wrong package

A device receives an update signed by a trusted publisher. The package targets another model or contains a version below the permitted minimum. Signature verification establishes authenticity of signed data, but does not independently establish compatibility or version-policy compliance.

Check signature, model identifier, supported revisions, version, and installation prerequisites. Critical metadata must receive integrity protection with the package. If the model field can be altered outside the signed scope, checking it provides only apparent protection. Publisher and device must interpret the manifest consistently.

NIST SP 800-193 frames firmware resilience through protection against unauthorized changes, detection, and recovery. In our scenario, correctly rejecting an installation is therefore insufficient to assess the complete process. The team must also know how the device recovers from interrupted writes and damaged images.

Test modified packages, wrong models, old versions, insufficient storage, and controlled power interruption. The local model receives a precomputed signatureVerified result and performs no cryptographic operation. Passing it verifies policy logic, not signature implementation or bootloader security.

A trusted publisher can also fail

Compromise of the signing key changes the situation: an attacker can produce a package that passes ordinary authenticity checks. Appropriate key access, separation of release permissions, operation records, and response planning are needed. Securing download transport does not replace protection of the process creating trusted artifacts.

Key rotation and revocation must work for devices that do not connect daily. Define what happens to an older fleet and how legitimate updates avoid becoming blocked. Recovery must not become an undocumented route bypassing every control, because that creates an alternative installation channel.

Rollback prevention also has an operational cost: it can prevent an easy return after a defective release. Provide a policy-compliant recovery path, such as a higher-numbered release restoring the required behavior. Design rollback protection and recovery together, including configuration and stored-data compatibility.

Connect scenarios to verifiable controls

The telemetry-service team may own S1, identity and service-tool teams S2, and release engineering plus firmware S3. Shared responsibility without a specific owner often means each participant assumes someone else will finish the work.

NISTIR 8259A provides a reference for core IoT device cybersecurity capabilities. Use it to check coverage of identification, configuration, data protection, interface access, updates, and cybersecurity state awareness. A capability list helps assess scope but does not establish implementation effectiveness.

Requirements should specify observable outcomes. “Provide authorization” is too broad. “Reject D-A requests claiming account B before writing to any data store” defines a condition, boundary, and effect. Tests can then examine whether all storage paths, including asynchronous work, enforce that rule.

Residual risk needs an owner

Not every scenario can be eliminated. Distinguish absent, planned, implemented, and verified controls. Marking a control green when a backlog task is created is misleading. A unit test of a rule is also different from an end-to-end test involving the actual database and queue.

Prioritization should consider consequence, access required, scale, detectability, and recovery. Without probability data, descriptive categories with explanations are preferable to multiplying arbitrary numbers and presenting the result as precise measurement. The rationale for work order matters more than a decorative score.

Risk acceptance should identify an owner, conditions, and review trigger. For example, offline service might be permitted only for read access on devices in controlled locations. Expanding it to configuration changes requires revisiting that decision. Risk belongs to a function and scope, not permanently to the product name.

The model evolves with the product

A new user role, shared export, local service interface, update supplier, or ownership-transfer flow should trigger review of relevant scenarios. There is no need to start from a blank page each time. Identify the flows and assumptions affected by the change.

Review removed features too. Closing an endpoint does not prove that older applications, scheduled tasks, or service packages stopped using it. A retained compatibility path may preserve earlier permissions. Check actual entry points and behavior of previous client versions.

Incidents and test findings add knowledge to the model. If one flow omitted a control, look for the same assumption elsewhere. The objective is not an enormous table containing every defect, but an updated shared understanding of trust boundaries and how they are enforced.

Provisioning and access recovery

An identity registry does not create itself. Define how a new device receives credentials, who may assign it to an account, and how that association is confirmed. A fleet-wide shared secret may simplify a prototype, but its disclosure changes incident scope. The model should establish whether losing one unit exposes only that unit or others as well.

Recovery after losing a phone or technician computer matters as much as normal login. If it bypasses strong controls using an easily available serial number, it becomes a simpler takeover route. Define proof of entitlement, exception approval, and audit evidence. Support convenience should not depend on a permanent shared account with unrestricted permissions.

Device retirement requires a policy for keys, local data, and account association. Resetting user settings may leave credentials intact. Conversely, accidentally erasing factory identity may prevent legitimate recovery. Distinguish configuration reset, ownership transfer, and permanent retirement because they have different effects.

A denial test needs an allowed counterpart

A security test can appear to pass because the entire service is broken. Rejecting a foreign-device request due to a network outage does not establish correct ownership enforcement. Run an allowed operation under the same conditions and confirm that it reaches the proper resource. This distinguishes a decision test from incidental unavailability.

Also verify absence of side effects. A denial response is insufficient if data was already stored, a command queued, or a file exposed. Observe the relevant transaction boundary and subsequent asynchronous tasks. Some systems require a defined waiting interval to detect delayed effects.

Use controlled accounts, devices, and test data. Associate results with an exact release and configuration. Changed permission caching or a new queue consumer may invalidate earlier evidence even if token-checking code remains unchanged. The model exposes that dependency and helps select a retest scope.

A working record for the team

This record lets a discussion end with concrete work: a contract change, implemented control, test, or deliberate feature restriction. A useful model supports those decisions and preserves their basis. A diagram without evidence links quickly becomes a statement of intent that nobody can verify.

The denial response also belongs in the model. A foreign account should not learn unnecessary details about a device’s existence, owner, or version. An access-controlled internal journal can retain a more specific diagnostic reason. Separating public and operational information avoids turning a correctly blocked operation into a source of information about another account. Test response content and side effects as well as its status code. A technically correct denial can still reveal information outside the caller’s permitted scope.

Sources

• OWASP Threat Modeling Cheat Sheet, system description, trust boundaries, scenarios, and verification; continuously maintained documentation.
• OWASP Authorization Cheat Sheet, default denial, least privilege, and per-request checks.
• NISTIR 8259A: IoT Device Cybersecurity Capability Core Baseline, May 2020; core device capabilities.
• NIST SP 800-193: Platform Firmware Resiliency Guidelines, May 2018; firmware protection, detection, and recovery.

Sources checked on 21 October 2026. Scenarios and rules are educational. No system audit, penetration test, or cryptographic validation was performed; this article does not establish regulatory compliance.