The document as a whole reads very well, thanks for all your work on it. I do hope it enjoys wide adoption.

Abstract:
I thought one of the goals was to update firmware for IoT, but also to scale up to larger systems as well. The abstract seems very specific to constrained devices. Should the language be adjusted or has the focus changed?

Introduction:
If the scope does include larger devices, then this is a problem for them as well for both security and inconsistency across platforms. It's harder than it needs to be and that's amplified when you think about IoT.

Section 2:
For the Firmware definition, is the last sentence referring to both "firmware" and "image" as interchangeable or something else? I think adjusting the last couple of sentences may be helpful to some readers.

Section 3.2:
If not link, network, or transport layer security, what does this rely upon? If it is object-level security and I am assuming it is, please state that explicitly possibly referring to where confidentiality protection is specified.

Section 3.3:

Current text:
"The use of post-quantum secure signature mechanisms, such as hash-
based signatures, should be explored."
Since this is the architecture document, if they are defined elsewhere, the document should point to that rather than saying "should be explored".

Some other well received architecture documents provided pointers to the related documents that filled out stated components of the architecture. If the WG were to hold this to be published until other document were complete, this could provide the same mapping between the requirements, architecture, and implementation of the architecture with the various specifications.

Section 3.6
I think this is the first time "fw" is used. Maybe just spell out firmware with a search and replace?

Section 3.11:
Typo in the following sentence:
"TEEs may obtain TAs from different authors and those TAs may
require personalization data, such as payment information, to be
securely be conveyed to the TEE."
s/to be securely be conveyed/to be securely conveyed/

Section 4;
Typo in the following sentence:
"The credential used to must be directly or indirectly
related to the trust anchor installed at the device by the Trust
Provisioning Authority."
s/The credential used to must/The credential used must/

Section 8
This says downloads can be large, so I think that's to accommodate more than IoT, is that right and the abstract/intro can be updated?

The following sentence is readable, but super long:
If the application image contains the firmware consumer
functionality, as described above, then it is necessary that a
working image is left on the device to ensure that the bootloader can
roll back to a working firmware image to re-do the firmware download
since the bootloader itself does not have enough functionality to
fetch a firmware image plus manifest from a firmware server over the
Internet.
Perhaps break it up?

Security considerations:
Should this mention the end-to-end encryption? Is it provided at the object level?

Also, if the intent is to scale above constrained devices, the text should state that as this section also specifies IoT.

Thank you for all of your work on the document. It's easy to read and comprehensive.

Section 2 currently contains the RFC 2119 boilerplate about normative language.
However, none of those terms are currently used anywhere in the document, and so the boilerplate can be removed and RFC 2119 removed from the references section.