IoT device estate: from use case to profile
A use case in the shape the template sets out, developed as far as it can be without the working group. The sections that could be argued from the methodology are written; the sections that need a decision are marked and left open. Nothing here is a profile yet, and no rules file exists.
Why IoT is not yet a use case
Every other entry in this section names a consumer and a decision. IoT names neither. It names a class of subject: devices that are numerous, constrained, deployed somewhere nobody visits, and expected to keep working for a decade or more. Several different consumers make several different decisions about that class, and they need different profiles.
So the first piece of work is choosing which decision to develop. Three are plausible, and they are genuinely different rather than three descriptions of one.
| Candidate | Consumer and decision | Why it might be the one |
|---|---|---|
| Fleet remediation proposed |
An operator of a deployed estate deciding, per device model, whether to update it, replace it, put something in front of it, or accept it | It is the decision the constraints actually bite on, and the one no existing profile serves. The migration profile assumes a negotiable interface and an update path, and a large part of an IoT estate has neither. |
| Device procurement and certification | A buyer or certification body checking a device against a scheme before it is bought or placed on the market | Closer to the procurement and compliance entries already in the catalogue, and possibly served by a depth of one of those rather than by a profile of its own. |
| Manufacturer support planning | A manufacturer deciding which of its shipped models to carry forward and which to end | The producer and the consumer are the same party, which is a different situation from every other use case here and probably needs no disclosure profile at all. |
The rest of this page develops the first. The other two are recorded so that choosing the first is visibly a choice.
1 · The decision being supported
An operator runs an estate of devices it did not build, cannot inspect, and in most cases cannot reach without sending somebody. Cryptography on some of those devices will have to change. For each device model in the estate the operator is choosing between four actions, and they differ by orders of magnitude in cost.
- Update in place. New firmware carries the new algorithms. Cheapest, and available for a minority of the estate.
- Replace. On a schedule, at a unit cost multiplied by the number deployed, plus the cost of physically reaching each one.
- Put something in front of it. Terminate the protected session at a gateway that can carry the new algorithms, and leave the device alone. Cheap where the topology allows it and impossible where the device talks directly to the outside.
- Accept and document. The device outlives the exposure, or the data it carries does not warrant the spend. A legitimate answer that has to be defensible.
Five questions decide between them.
- Can this model carry the algorithms at all, or do its memory, compute and message-size limits rule them out whatever firmware it runs?
- Is there a mechanism to get new firmware onto it, who is able to trigger that, and for how long will it still be offered?
- Is the key material replaceable, or was it fixed at manufacture?
- Does the cryptography for this interface terminate on the device, or somewhere we control?
- How long will this model stay in the field, and does that outlast the exposure?
Only the third and fourth are close to anything the interface disclosure baseline asks. The first is a statement about the device rather than about the interface, which is unusual. The second is a statement about a process, which is more unusual still, and is the one most likely to be argued about.
2 · The constraint the producer is under
The black-box constraint applies, as it does to every profile whose producer is a vendor. Four further constraints apply here, and together they are what make this a separate use case rather than a sector flavour of PQC migration.
The producer knows the model, not the deployment
A device manufacturer knows what it shipped. It usually does not know how any particular unit was configured, what it was connected to, or whether it is still switched on. The document therefore describes a model, and the decision is made about instances of that model. Everything that varies per instance has to be joined in by the operator from its own inventory, and the CBOM does not carry it.
Some limits are physics, not policy
Elsewhere in this methodology, a statement that an interface cannot do something is a statement about what has been built and could be built differently. On a constrained device it is often a statement about available flash, available RAM, or a frame size fixed by a radio standard. No firmware release changes those. This is the only use case here in which a capability answer of "no" can be permanent, and a profile that cannot express the difference tells an operator to wait for an update that will never come.
The party who can update may be neither the vendor nor the operator
Firmware often reaches a device through a third party: a connectivity provider, a platform operator, an installer with physical access. The operator making the decision may have no relationship with that party. A profile that records only whether an update exists, and not who can cause it to happen, leaves the operator unable to tell an available action from a theoretical one.
Field life outlasts the support commitment, and sometimes the vendor
A device installed today may still be running in fifteen years. The commitment to ship firmware for it will not last that long, and neither, in some cases, will the company that made it. This is the same problem as the long-term stewardship question the working group already tracks, arriving from the device end rather than the profile end.
3 · From questions to attributes
Each question from section one turned into facts that a manufacturer could declare about a model. The right-hand column says whether the attribute exists already, which decides how much of this is a new profile and how much is a tightening of an existing one.
| What the consumer needs to know | Proposed attribute | Status |
|---|---|---|
| What is this interface and what does it speak? | interfaceType, protocol, protocolVersionsSupported | Baseline. The value set for interfaceType probably needs extending; see below. |
| What is it doing now, and what else could it do? | keyExchange, authentication, and their Supported counterparts | Baseline and migration profile. |
| Could any firmware carry the new algorithms, given what the hardware is? | resourceBound | New. The hard limits that bound what this model could ever negotiate: usable flash and RAM headroom, and the maximum frame or message size the link imposes. |
| Is there a way to get new firmware onto it? | updateMechanism | New. none · physical-access · local-network · remote-managed. |
| Who can trigger that? | updateAuthority | New. operator · vendor · platform · installer. The attribute that separates an available action from a theoretical one. |
| Will firmware still be offered? | updateSupportStatus | New. A commitment class rather than a date, following decision 0007: supported · limited · ended · never-offered. |
| Can the keys be replaced? | keyProvisioning, keyReplaceable | New. Where key material came from, and whether anything short of replacing the device can change it. Factory-injected material that cannot be rotated is the case that turns an update decision into a replacement decision. |
| Where do key operations execute? | providerLocation | Migration profile, but the value set is wrong here: software, hsm, tee and unspecified do not cover a secure element, an MCU's internal flash, or one-time-programmable fuses. |
| Does the cryptography terminate on the device? | cryptoTerminationPoint | New. device · gateway · both. The attribute the compensating-control option turns on, and the one most likely to be contested, because it is arguably a deployment fact rather than a product fact. |
| What breaks if we do change it? | integrationConstraints | Migration profile. Here it has teeth it does not have elsewhere, because a post-quantum handshake may simply not fit. |
| How much should we trust this record? | lifecycleStage | Baseline. |
Interface types a device has that a server does not
The baseline's product rule P2 requires a management interface or a statement of why there is none, which is a rule written for products that are administered. Many devices are not administered at all, and the escape clause carries them, though a profile for this use case should say so rather than leaving every producer to discover it. Four interface kinds recur on devices and have no obvious home in the current value set: a provisioning or onboarding interface used once and never again, a firmware update channel, a radio link with cryptography fixed by its own standard, and a telemetry uplink that is one-way.
Questions that may not survive
Two of the five questions from section one may not be answerable by a document at all, and that is a finding rather than a gap to be filled.
How long the model will stay in the field is a fact about the operator's estate, not about the product. The manufacturer can state how long it will support the model, which is updateSupportStatus; how long the operator will keep running it is the operator's own planning input.
Whether a gateway can carry the cryptography instead is a fact about a deployment. cryptoTerminationPoint is an attempt to get at the part of it that is a product fact: whether the device's design permits termination elsewhere. Whether it has been deployed that way is not something the document can say.
4 · The profile definition
One structural question has to be answered before any rule can be written, and it is not a detail. This profile is not a deeper version of PQC migration. It supports a different decision, with a different action set, and it adds attributes the migration profile has no use for while ignoring several the migration profile requires. In the terms used under composition in Profile, it is a branch rather than a depth, which means it extends the interface disclosure baseline directly rather than extending the migration profile. It is carried as Q64 because the alternative is arguable: an estate of gateways and an estate of sensors are being planned by the same person, and two unrelated profiles make that harder rather than easier.
The relationship to the base, once Q64 is settled: one table with three rows for inherited, tightened and added.
Product-level rules. At least one is needed that the baseline does not have: a device with no update path at all is the single most consequential fact in this use case, and a rule that only ever fires per interface will let it go unstated.
Per-interface rules for the attributes in section three, each with a conformance level and a note saying what a consumer does with it.
Tightenings, with a justification each. One candidate is already visible: if resourceBound is required at MUST then integrationConstraints, which the migration profile leaves at SHOULD, is arguably the thing that explains it and should rise with it.
Conditional rules. Two are implied by section three: updateAuthority and updateSupportStatus only mean anything where updateMechanism is not none. Remember that a guard may be removed by a derived profile but never added or narrowed.
5 · A worked interface
One real interface on one real device model, filled in completely. The candidate worth using is the least convenient one: a battery-powered sensor reaching a gateway over a constrained radio link, where the honest answer to several attributes is that the model cannot do it and never will.
| Attribute | Value | What it tells the consumer |
|---|---|---|
interfaceId | … | … |
interfaceType | … | … |
protocol · protocolVersionsSupported | … | … |
keyExchange · keyExchangeSupported | … | … |
authentication · authenticationSupported | … | … |
resourceBound | … | … |
updateMechanism · updateAuthority · updateSupportStatus | … | … |
keyProvisioning · keyReplaceable | … | … |
providerLocation | … | … |
cryptoTerminationPoint | … | … |
integrationConstraints | … | … |
lifecycleStage | … | … |
Then the same interface on a device that can be updated, so the two can be read against each other. The pair is what shows the profile separating the four actions rather than describing them.
6 · What the profile deliberately excludes
Three exclusions can be argued now. A fourth is open.
No device verdict. Whether a device model is quantum-safe, or safe at all, is a judgement against criteria that change while the device sits in a field. The profile states facts and an external policy reaches the verdict, dated. This matters more here than elsewhere because the device will outlive several revisions of the criteria.
Nothing per instance. No serial numbers, no locations, no deployment configuration. The producer does not know them, and a profile that asks for them is unsatisfiable by the party that has to fill it in. The operator joins its own inventory to the document; Objects sets out why the subject of a document and the subject of a decision are separate objects.
No firmware component inventory. What libraries the firmware is built from is an SBOM question. The overlap is real and the boundary is the one drawn in Model; restating it here would put the same requirement in two places.
Whether the physical attack surface is in scope. Debug ports, unlocked bootloaders and readable flash decide whether key material can be extracted, which bears directly on whether replacing the device is necessary. It is also a security posture question rather than a cryptographic disclosure question, and admitting it would widen this profile considerably. Argue it explicitly, either way.
7 · Expressing it in a CBOM
Which of the new attributes map to native CycloneDX and SPDX fields and which become properties under the pkic:profile: namespace. Most of them will be properties; resourceBound is a structure rather than a value and needs the most care.
How the subject is identified, given that it is a model. This is the part to settle first: a document whose subject is ambiguous between a model and a unit cannot be joined to an estate inventory reliably, which is the whole of what the consumer does with it.
What a producer records when it does not know. unknown has to be available on the update attributes in particular, because a manufacturer genuinely may not know who can push firmware to a unit it sold through a channel.
8 · Recorded decisions and open questions
No decision records yet. Four questions are carried in the open questions register, and they are the four that block writing the rules.
| # | Question | Topic |
|---|---|---|
| Q62 | Is the subject of a CBOM a device model or a deployed device, and does the methodology need to say which? | 3.3 |
| Q63 | Does the methodology need a way to say that a limit is permanent rather than a current state? | 3.3 |
| Q64 | Is an IoT profile a branch from the baseline or a depth of the migration family? | 3.9 |
| Q65 | May a profile require a fact about a process, such as who can push firmware, rather than about a product? | 3.4 |
What this page needs next
In order, because each depends on the one before it.
- Confirm the consumer and the decision, or pick one of the two alternatives instead.
- Settle Q64, which decides what the profile extends and therefore what it may tighten.
- Settle Q62, which decides what the subject is and therefore what the product rules can say.
- Write the rule tables in section four and the rules file together, then run
check_profile.pyagainst it for C1 to C17. - Fill in section five with two interfaces, one that can be updated and one that cannot.
- Add a conforming and a non-conforming document, and a test in
tests/run-profile-tests.shthat asserts both.
Until step six the overview page lists this as a draft. That is the correct state for it, and the reason for having the page at all: a draft that names its consumer and its constraints is something the working group can argue with, which is more than an empty slot in a table offers.