Skip to main content

​
What this integration contributes

Adaptive Security can contribute workforce, training, and multi-channel simulation outcomes. Reviewed examples include:
  • phishing.simulation.clicked — clicked a simulated email without reporting it
  • phishing.simulation.credential.submitted — entered credentials on a simulated sign-in page
  • phishing.simulation.attachment.opened — opened an attachment on a simulated email
  • phishing.simulation.reported — reported a simulated email
  • smishing.simulation.replied — replied to a simulated text message
  • vishing.simulation.succeeded — complied with a simulated voice caller
  • training.assigned — assigned security training
  • training.completed — finished security training
  • training.past.due — missed a training deadline
These examples show the types of normalized activity Living Security can use. See how integration data becomes signals.
Adaptive simulates over three channels, and Living Security scores each one separately. Email outcomes score as phishing, text-message outcomes as smishing, and voice-call outcomes as vishing. A person who clicks a simulated email and one who replies to a simulated text are not measured as the same behaviour, because the judgement each one made is different.

​
What Living Security needs

Required role: An administrator on your Adaptive Security account with access to Settings → API. Adaptive governs API access with role-based permissions, so the token must belong to a role that can read users, phishing and training. Access: Read-only. Living Security only reads from Adaptive Security and never creates, changes, or deletes anything in your account.

​
What Living Security retrieves

Phone numbers are not stored. Adaptive returns office and mobile numbers on its user record. Living Security discards both before storing anything, because no Living Security feature uses them.
Adaptive’s own risk score is recorded but never scored. Adaptive computes a current_risk_score per person. Living Security keeps it so you can compare the two systems side by side, but the Human Risk Index is always calculated from observed behaviour using Living Security’s own published model — never from another vendor’s composite score.

​
Prerequisites

  • An Adaptive Security account with the API enabled.
  • Administrator access to admin.adaptivesecurity.com.
  • User email addresses in Adaptive that match the addresses your other connected systems use. Email is how Living Security matches an Adaptive user to a person.

​
Part A — In Adaptive Security

Your Adaptive Security administrator completes these steps.
1

Open the API settings

  1. Sign in to admin.adaptivesecurity.com as an administrator.
  2. Go to Settings → API.
2

Generate the API token

  1. Generate a new API token.
  2. Give it a name you will recognise later — for example Living Security.
  3. Confirm the token’s role can read users, phishing campaigns and training campaigns.
  4. Copy the token.
Copy the token before you leave the page. If your Adaptive account sets an expiry on the token, note the date — Living Security cannot retrieve data after it expires, and the connection has to be updated with a new token.

​
Part B — In the Living Security Platform

The program owner completes this step, or the system admin if using delegated setup.
You are now connected to Adaptive Security.

​
How often data is retrieved

Adaptive’s reporting API does not offer a “what changed since” filter, so Living Security reads each simulation and training campaign while it is still producing outcomes, and stops reading it once it has been closed for two weeks. Late clicks and late reports are therefore still captured, and finished campaigns are not re-read for ever.
A first connection on a large Adaptive account can take several scheduled runs to finish reading everything. Each run reads as much as it can and the next one continues from where it stopped, so counts climb over the first day or two rather than appearing all at once.

​
Troubleshooting

The API token is wrong, expired, or was revoked. Adaptive returns an empty response body on this error, so there is no further detail to read. Generate a new token in Settings → API and reconnect with it. A partially-copied token produces the same error, and is the most common cause.
The token authenticated, but its role cannot read the data being requested. Re-pasting the same token will not help. In Adaptive, confirm the token’s role has read access to users, phishing and training, or issue a token from a role that does.
Adaptive rate-limited the connection. Living Security stops that run and resumes from the same place on the next scheduled run, so no data is lost — counts simply take longer to climb. If this persists across days, contact Adaptive Security support to ask about the rate limit that applies to your account.
Check that the campaigns you expect have actually run. Adaptive reports enrollments only for simulations that have been sent, so a campaign still in Draft or Scheduled status contributes nothing until it goes out. Living Security deliberately does not read those, so that it spends its request budget on campaigns that have real outcomes.
Living Security decides the channel of each outcome from the scenario attached to it. If a scenario was deleted in Adaptive after its simulation ran, its outcomes are recorded against the email channel, because the channel can no longer be read. Keeping retired scenarios in Adaptive rather than deleting them avoids this.