My experience jades me. I did IT Security Audits in my career path. The promise of future delivery was rarely accepted. A minimum level of security must be implement before release. Releasing products that don't meet minimums waters down the security requirement.

Bluetooth has four security levels. Security level 1 supports communication without security at all. The product is being released under security level 1 with the future promise of security level 4. What happens to the 100K units that are sold under security level 1?

There is post by NW that is a perfect example LittleBits Droid of the consumer being left holding the bag after a product is no longer viable. It is a slippery slope to work on the premise of a promise made is a promise kept. Security minimum are important before, on and after the product is released, no compromise.

I agree with you, that it would be ideal to have security have the same relevance as safety during product development.  I think I could live with lower levels of security during the pilot or exploratory phase of product development, so long as there was consent by the end users.  For example, Here is our product with the following security limitations which we intend to address in an upcoming release.  If the manufacturer is still piloting the product, this makes sense from a time to market approach and getting the feedback needed to eventually produce a mass market product.

During this pilot phase the developers could get a better understanding on how end users are actually deploying or using the product.  Getting a better understanding of the use cases would help with developing the appropriate security solutions and prioritizing development appropriately.

It would be ideal, if security was given the same relevance as safety in product development. Consumers are ignorant, naive and trusting. Product developers are driven by profit. Without a security standard both developers and consumers are left to fend for themselves.

I read through the Security eBook and it did a very good job covering the technology available to secure an IoT device.  There were some gaps and approaches that I would take differently.

The eBook did not cover the topic of secure boot and firmware authentication.  This is a pretty advanced manufacturing/engineering topic where admittedly the workflow and business processes are probably more complex than the technology to implement.  Private keys are burned into the controllers or other chips on the main PCBA and later used to validate that the firmware being installed is authentic and comes from the manufacturer.

I also think some time should be spent to discuss why IoT devices are often not secure.  This is often because small start-ups are more concerned with validating the market place for a new application than the security.  After all, if there is no demand for a given product/service why spend any time securing it.  Once a concept has been validated, and the company is starting to get some traction, then the investment in security must be made before the product volumes begin to get too large.  I think that this is entering the realm of marketing but nonetheless it would help to explain the state of IoT security in the market today. 

Security needs to be evaluated along a matrix of level of risk and the associated impact of a breach, where the bulk of the effort is spent on reducing high impact events.

Great effort by the Element 14 team.