The recent development of high-security processors and hardware is substantially changing embedded software tools, shedding light on security in the embedded development environment. The process of developing, certifying, and implementing a secure processor has several challenges that can be compared to providing deadbolts for residential properties. The deadbolt itself, no matter how well designed and tested, offers little security if it isn't installed correctly. Even more significantly, the deadbolt is useless if the owner doesn't lock it at night. These problems are similar for secure hardware—if system developers implement them incorrectly and end users don't employ security configurations, the processor's security properties are of no value in the end system. Instituting security policy in the hardware has all of the hallmarks of traditional security software: user authentication (security engineer only), preventing the impact of users or operating code on security settings, command integrity and verification, and keeping security policy audit log settings. In this article, the authors define the embedded end markets affected by embedded software assurance issues, then examine ways in which security and assurance capabilities are partitioned in hardware and software. They then examine the problems inherent to configuring secure hardware and offers a list of considerations and testing issues for providers interested in improving their embedded security environments to support secure hardware and processors.