Everything CyBehave builds starts as a question about behaviour. The Lab is where those questions are worked through - the frameworks, models and studies behind our platforms, published openly so you can see exactly what we measure, how, and why.
Grouped by stage. Open a stage to see the work in it, then open a row to read more.
Which interventions actually shift behaviour, how long the shift lasts once attention moves elsewhere, and what has to be in place for a change to embed rather than rebound.
Decay is the part the industry tends to skip. An intervention that works for six weeks and is never measured again is indistinguishable from one that did nothing.
What happens to security behaviour and culture during a major disruptive event - an incident, a merger, a disposal, a change of strategy - and whether the damage can be anticipated and managed rather than discovered afterwards.
Early work, but the pattern is familiar enough to be worth studying properly: attention spikes, then the programme absorbs the disruption and quietly loses ground.
Testing whether behaviour observed by colleagues, gathered in waves across the year, gives a more honest read on security behaviour than self-report or click-rate.
In scope: how many waves a year is enough, how observer bias shows up and what dampens it, and whether a peer-observed score moves in ways that survive scrutiny from a sceptical board.
What makes a champion network hold together rather than quietly decay: tenure effects, coverage, position in the informal structure, and which signals predict a programme running out of energy before the sponsor notices.
Closely tied to SCIM. The practical question is whether decline can be seen early enough to do something about it, rather than explained afterwards.
Most champion programmes recruit whoever volunteers and hope influence follows. SCIM asks whether where a champion sits in the informal network predicts how much they shift the behaviour of the colleagues around them, so that a programme can place champions on evidence rather than on enthusiasm alone.
Systematically assessing how each established human cyber risk concept maps to AI agent behaviour, and classifying the strength of each analogy rather than asserting that the whole thing transfers.
The work is ongoing because the ground keeps moving. Agent capability changes faster than the literature about it, so the classifications are reviewed rather than fixed.
Nudge and boost were borrowed from health and public policy, where whoever designs the choice is broadly on your side. Security is different. The person arranging the choice in front of you is often an attacker, and in our experience the borrowed tools have produced only narrow and inconsistent successes here.
Brace is our proposal for a third class of behavioural intervention, sitting alongside nudge and boost and designed for the case where the choice architect is hostile. The paper introducing it is available as a preprint, and a field trial is planned to gather evidence for a follow-up. Until that evidence exists, Brace is a working position rather than a finding.
Read the preprint on SSRN →Security culture reaches people through repetition, social proof and identity. An AI agent absorbs none of that, but it will read a file and act on it literally, thousands of times a day. The normative repository is a single, version-controlled, cryptographically signed store of an organisation's charter, security, privacy, ethics, safeguard and escalation norms in a form agents can consume. Agents load a signed release when they start work, re-check it on a fixed cadence, and log which release they were operating under.
That schedule doubles as a compromise signal. Because every agent is expected to renew its norms, a missed attestation or a stale hash is evidence that an agent may have been hijacked or has drifted. The preprint is conceptual and reports no empirical results. It closes with four testable propositions and a pilot design, so this is a working position rather than a finding.
Read the preprint on SSRN →Ask a champion programme whether it is working and the answer is usually a list of what it did: champions recruited, sessions run, tasks completed. The people reporting are the people who run it, and composites built from one set of raters correlate whatever the world does. This paper reviews the research on champion programmes, maturity models and readiness, and the measurement problems underneath all three, then describes how Heroes was designed to avoid them.
The design keeps readiness and maturity apart, draws its three headline measures from three separate rater populations (the programme and security team, the champions, and the champions' colleagues), withholds a headline when the evidence behind it is missing rather than scoring the gap as zero, replaces level bands with a reliable-change threshold, and treats the champion network itself as something that matures. It is a design-science paper: an instrument and the reasoning behind it, with no empirical validation yet. The test-retest and cross-tenant studies it calls for are the next step.
Read the preprint on SSRN →A structured assessment of behavioural readiness, staged against recognised maturity thinking, giving security leaders a defensible starting position rather than a vendor score out of ten.
It reports where a programme is constrained rather than only how it scores, on the grounds that knowing your weakest stage is more useful than knowing your average.
An eighteen-item self-assessment of a security champions programme across six dimensions of practice, from purpose and sponsorship through to measurement and impact. Most programme leads can count champions and events; far fewer can say which part of the programme is holding the rest back.
It reports the constraint dimension and three actions aimed at it rather than only a score, and it claims nothing about behaviour, because the programme's view of itself is one vantage point and the rater-disjoint work above explains why one is not enough.
Four bodies of published work. Each one is a standing output of the Lab, and each one feeds directly into the platforms. Open a row to read more.
Our six-stage behavioural change framework for cybersecurity: Specify, Hypothesise, Intervene, Embed, Learn, Diffuse. It gives a security team a repeatable way to move from a vague concern about behaviour to a tested intervention and an embedded change.
Built on COM-B and the Behaviour Change Wheel, but written for working practitioners rather than researchers. SHIELD is the backbone of how Heroes structures a programme, and it is free to use whether or not you ever buy anything from us.
Read the SHIELD framework →An adaptation of the Behaviour Change Wheel to security behaviour: 16 behavioural factors arranged across four concentric layers, from the individual outwards to the organisational conditions that shape what people actually do.
The model can be viewed through three lenses - human, AI agent, and convergent - which lets you ask whether a given factor behaves the same way for a person and for an autonomous system.
Explore the model →Our open question about whether human behavioural science can be meaningfully extended to understand, predict and govern AI agent behaviour - and whether the security industry is quietly solving the same problem twice under two different names.
Rather than asserting that the whole of behavioural science transfers, BCT assesses each established human cyber risk concept individually and classifies how strong the analogy actually is. Some hold well. Some do not hold at all.
Read the theory →The Behavioural Cyber Risk Skills Framework: 30 competencies across 7 domains and 5 proficiency levels, covering what a team needs to be able to do to manage human cyber risk properly.
Use it to assess where your team is now, to write a defensible job description, or to work out which capability gap is the one actually holding your programme back.
View the framework →Behavioural science attracts confident claims. Most of them are unearned, and the security industry has been sold enough of them already. So the Lab holds itself to a rule: the strength of a claim has to match the strength of the evidence behind it, and both get stated.
In practice that means we will tell you when something is grounded in replicated research, when it is a reasonable inference we are testing, and when it is a hypothesis we happen to find persuasive. Those are three different things, and collapsing them into one confident sentence is how the field ends up back where it started.
It also means we will change our position when the evidence does. Anyone promising a solved formula for human cyber risk is selling certainty the science does not yet support.
Replicated in peer-reviewed research across multiple studies and settings. We state it plainly and cite it.
Good evidence exists, but from a narrower base than we would like. We state it with the limits attached.
A reasonable inference we are actively running studies on. Described as a working position, never as a finding.
A question we are shaping. Published as thinking, flagged as such, and open to being wrong.
Science that stays in the journal changes nothing. Every framework here is built into something a security team can pick up on a busy Tuesday.
A new joiner learns how an organisation behaves long before they read a policy. They watch who gets challenged...
Read insight →Picture a finance officer on a Thursday afternoon. An email arrives from a supplier she has dealt with for yea...
Read insight →Most organisations treat security behaviour as a plumbing problem. There is a pipe. Training goes in one end; ...
Read insight →Every framework the Lab publishes is free to read and free to use. Start with SHIELD, or see how the research is applied in practice.