Are We too Early for the Party? (the perils of Baking Cyber in from the Beginning)

The speakers, who do cyber security work on a civil aircraft program, open with the familiar claim that security belongs in a project from day one. They describe their current position: an uncrewed aerial vehicle is heading into civil certification, and much of the design still exists only as block diagrams. Early involvement brings friction. Product teams resist added requirements, leadership prioritises certification over security, and architecture changes repeatedly, which forces threat models to be rebuilt.

They also set out the benefits. Early requirements reduce rework and hardware respins, and tracking testing from the start makes the documentation regulators need easier to assemble. Their approach was to reach out to product teams rather than wait to be invited, build governance and policy to anchor work as things shift, and model only the tangible system boundaries instead of every external factor. Agile sprints were a recurring obstacle, so they split security work into phased tickets that fit into delivery cycles.

The main takeaway is that early involvement helps but is not easy. Practitioners in this position should expect a documentation and advisory role rather than hands-on testing, plan for flexibility, and use relationships and advocacy with managers to make risks visible. The audience questions covered handling schedule pressure in conversations with product managers and fitting security into agile workflows.