Richard Wilkins  of Phoenix Technologies has an article in Embedded Computing about UEFI-based IoT security:

[…]This article is focused on system startup/firmware and the potential security problems for IoT devices in that space. And most important, what to do about them.[…]

http://www.embedded-computing.com/articles/firmware-security-for-iot-devices

PS: RANT… for some reason, one sentence jumped out at me:

“So why isn’t everyone using UEFI firmware? If the UEFI architecture provides the “solution” to these security threats, why isn’t everyone using it?”

I think the answer: UEFI is *A* solution, there are other solutions. Coreboot with Heads is another solution. Coreboot with Verified Boot is another solution. Using TXT and TPM measurements are other layers. Hypervisors/TEEs/SEEs are another layer. Separate security processors are another way. What is the right way, why isn’t everyone using one way? While I am a UEFI Forum member, I don’t think UEFI everyone should be using it. I welcome firmware diversity. 🙂 IMO, there are multiple implementations of signed code, signed updates, and a signed boot-up process, controlled by multiple (not a single) organization. I’m still hoping to see some professor gets a grad student to write a report doing a proper comparision of the various modern firmware security implementations’ strengths, so someone can start to make a reasonale decision as to which firmware security architecture is the solution for them.