This talk shares our engineering experience from designing and implementing an open-architecture secure element — a type of chip that is traditionally closed and opaque. We’ll outline the practical consequences of choosing openness as part of the security model: how it affected hardware architecture, firmware design, verification, and development workflows. The session dives into concrete technical areas including the secure boot chain, attestation and update flow, key storage isolation, and the testing and fuzzing infrastructure used to validate the design. It also covers the boundaries of openness — where third-party IP, export control, or certification requirements force certain blocks to remain closed — and how we document and mitigate those limits. We’ll present anonymized examples of external security evaluations, show how responsible disclosure and transparent fixes improved resilience, and reflect on what “community-driven security” means in a hardware context. Attendees should leave with a clearer view of what it takes to make security verifiable at the silicon level — and why that process is never finished.