State one precise claim and outline the three technical blocks.
ContributeTechnical Contribution Standard
Share an engineering decision worth examining.
We welcome external contributions that help practitioners understand a real security decision: the system around it, the constraint that made it difficult and the evidence behind the chosen approach. Start with the short contribution template so we can assess the idea before asking you to invest time in a full draft.
The strongest contributions make three things clear: the architecture, the engineering trade-off and the evidence behind the decision.
Submission flow
Start with the decision structure.
You do not need to write a finished article first. Complete the technical contribution template and send that as the starting point. It gives us enough context to understand the system boundary, the engineering problem and the evidence behind the proposed decision before we ask you to develop a full draft.
We check the proposal for technical substance, evidence and editorial independence.
If the proposal is a good fit, we will invite you to turn it into a full article for review.
Before the three blocks
State the claim under review.
A clear claim helps us understand where your contribution adds value. Use one or two sentences to define exactly what you intend to demonstrate. “Vehicle cybersecurity” is a topic; a defensible statement about a specific trust boundary, control limitation or assurance decision is a claim.
Example
Signed firmware does not provide sufficient software trust when the build pipeline and signing authority remain outside the ECU manufacturer's assurance boundary.
Required structure
Three technical blocks. One clear engineering story.
01
Architecture & Trust Context
Define the cyber-physical system precisely enough that the reader can see where trust begins, where it ends and which interface creates the security problem.
- System, subsystem or operational process under analysis
- Trust boundaries and ownership boundaries
- Relevant interfaces, protocols or data paths
- Operational or safety dependency
- Threat, failure or misuse scenario being analysed
Useful level of detailDescribe the attack surface between a telematics control unit, its external connectivity and the in-vehicle network rather than referring generically to “a connected vehicle”.
02
Engineering Constraint or Regulatory Friction
Show what makes the security decision difficult in the real system, including the conditions that make a straightforward control incomplete, impractical or operationally unsafe.
- Technical or architectural constraint
- Safety, availability, latency or lifecycle constraint
- Relevant regulatory, standard or assurance requirement
- Supplier, ownership or integration boundary
- Why the straightforward mitigation may be insufficient
Useful level of detailShow the practical difficulty of meeting ISO/SAE 21434 assurance objectives when cryptographic key management depends on supplier components without an appropriate hardware root of trust.
03
Decision, Trade-offs & Evidence
Show how the decision was reached and why it can be defended. We are interested in the alternatives considered, the compromises accepted and the evidence supporting the conclusion.
- Alternatives evaluated
- Selected design or assurance approach
- Engineering trade-offs and residual risk
- Verification or validation evidence
- Primary sources supporting material claims
Evidence can includeTARA outputs, architecture reviews, SBOM/VEX artefacts, penetration-test results, fault-injection results, verification records, logs, standards clauses or other inspectable technical evidence.
Editorial fit
Topics we are particularly interested in.
We welcome security decisions from industrial, OT/ICS, automotive, railway, product-security, software-supply-chain and other cyber-physical environments. The most useful contributions explain the friction between a control that looks correct on paper and the system conditions that make the real decision more complicated.