A new hire starts Monday, OneLogin provisions their laptop and apps on day one - and security training still starts three weeks later, when somebody remembers to send the invite. Last quarter's leaver, meanwhile, still has an active learner account. Connecting OneLogin to Cyber Aware turns enrolment into an identity event: every hire lands in training automatically and every leaver loses access the day they leave.
TL;DR
- Cyber Aware's published integration list covers Google Workspace, Microsoft 365, Zapier and a direct API - there is no native OneLogin connector.
- OneLogin's user event webhooks (created, updated, deactivated) are the trigger side; Cyber Aware's API or Zapier is the action side.
- The build: OneLogin user event, filter for active staff, create the learner in Cyber Aware, deactivate on the leaver event.
- Map OneLogin groups to Cyber Aware client cohorts before anything goes live.
- Test one synthetic hire and one synthetic leaver before pointing the flow at real staff.
Why this matters
Manual enrolment fails at both ends of the employee lifecycle. New starters miss their first month of security awareness training - exactly the window where an unfamiliar, freshly-provisioned user is likeliest to click a payroll-diversion or invoice-fraud phish. Leavers keep accounts that pollute completion stats and, on a multi-tenant MSP deployment, distort the client's reporting. One event stream fixes both failure modes.
OneLogin sits at the centre of identity for thousands of businesses: HR adds the worker to the HRIS, OneLogin provisions their apps, and every downstream system keys off OneLogin's directory. Training should key off the same signal instead of a CSV somebody emails around.
There is no native OneLogin app in Cyber Aware's published integration list - Google Workspace, Microsoft 365, Zapier and a direct API. That is not a blocker. OneLogin emits user events as webhooks and exposes its directory through a public API, and either can drive the Cyber Aware side.
Who this is for
Two audiences. First, internal IT and security admins who run OneLogin as the identity provider for their own company and want training to behave like every other app in the onboarding checklist. Second, MSPs who manage OneLogin for client tenants and need each client's directory to feed its own Cyber Aware tenant without per-client manual work.
Before you start
- OneLogin admin access with permission to create event webhooks or read the directory via API.
- A Cyber Aware account with API or Zapier access - the direct API is the cleaner path; Zapier works when you would rather not run code.
- A cohort mapping decision: which OneLogin group or directory maps to which Cyber Aware tenant or client. Write it down before step one.
- The gotcha: the leaver event matters more than the hire event. A missed hire costs a month of training; a missed leaver is a stale account sitting in an audit trail. Build and test the deactivation path first.
Step 1 - Capture the OneLogin user events
- In the OneLogin admin console, create an event webhook that fires on user creation and on user deactivation - OneLogin's eventing can push these to an HTTPS endpoint.
- Point the webhook at Zapier's Webhooks by Zapier trigger, or at a small endpoint of your own that calls Cyber Aware's API.
- Send one test event per type and confirm the receiving side logs it.
Expected result: a test payload arrives carrying at minimum the user's email, given name, family name and status. If a field is missing, add it in OneLogin's event payload settings before mapping anything else.
Step 2 - Filter and map the payload
- Only act on users with an active status - skip pending invites, contractors in groups you exclude, and shared mailboxes.
- Map email, first name and last name, and normalise the email to lowercase. Case mismatches between systems are the most common source of duplicate learner records.
- Apply your cohort mapping: OneLogin group to Cyber Aware tenant. For an MSP, this one rule decides which client the learner belongs to.
Expected result: one clean, deduplicated record per person, with the destination tenant decided before creation.
Step 3 - Create the learner in Cyber Aware
- Call Cyber Aware's API to create the user in the mapped tenant, or use the matching Zapier action.
- New learners follow the platform's standard enrolment behaviour: the welcome email goes out, baseline courses are assigned, and due-date reminders are queued on the normal cadence.
- On the deactivation event, call the deactivate or remove path so the leaver disappears from the active learner list the same day.
Expected result: a test hire appears enrolled with baseline training assigned; a test leaver vanishes from active learners.
Step 4 - Run a monthly reconciliation
- Export the active-staff list from OneLogin and the active-learner list from Cyber Aware once a month and compare them.
- Investigate both directions: learners with no OneLogin account (contractors and board members enrolled deliberately) and staff with no learner record (mapping gaps).
- Log the exceptions; do not auto-delete accounts you cannot explain. A deliberate exception is a footnote, not an error.
Troubleshooting
- No learner appears. Webhooks are event-driven - nothing fires until the next user event after go-live. Create one test user in OneLogin to prove the path.
- Duplicate learner records. A manual invite and the sync both created the user, or the email casing differed between systems. Disable the manual path for synced tenants and normalise to lowercase.
- The leaver is still active. The event only fires on deactivation in OneLogin. If staff are disabled by moving groups rather than being deactivated, add that event to the trigger.
- Learners land in the wrong client tenant. The group-to-tenant mapping is wrong or the group changed. Fix the mapping, move the learner manually, and re-test with a user from that group.
- Nothing sends at all. Check that the OneLogin webhook is enabled and that the Zap or endpoint returns a 200 - a failing endpoint can be disabled automatically by the webhook provider.
What to do next
Once identities flow correctly, the reporting side looks after itself: every overdue course and phishing failure feeds each learner's Human Risk Score, and leaver cleanup keeps that score honest. MSPs comparing platforms before committing to a stack can work through the white-label platform comparison to see how integration depth differs across vendors.
FAQ
Does Cyber Aware integrate with OneLogin natively?
No. The published integration list covers Google Workspace, Microsoft 365, Zapier and a direct API. The OneLogin connection is built with OneLogin's event webhooks or API on one side and Cyber Aware's Zapier actions or direct API on the other.
Is this real SSO?
It is identity-driven provisioning: OneLogin stays the source of truth for who exists, and Cyber Aware learner accounts are created and deactivated from those events. Federated sign-in for the training portal itself is not part of the published integration list - if your deployment needs SAML or another federation standard at the portal login, confirm the current position directly with Cyber Aware before you buy.
What happens to a leaver's training history and Human Risk Score?
The account leaves the active learner list, so the leaver stops counting in completion rates and risk reporting. Deactivating cleanly is what keeps the client's monthly numbers accurate - which is exactly why the deactivation path is the one to test hardest.
Can I enrol by department or location instead of everyone?
Yes - the filter in step 2 is where that decision lives. Key the filter on the OneLogin group, department or directory you want to enrol and leave everyone else untouched.
Do contractors without OneLogin accounts break the sync?
No - they simply never generate an event. Enrol contractors the way you do today (signup link or CSV) and let the monthly reconciliation in step 4 surface anyone both systems missed.
We already sync Microsoft 365 into Cyber Aware. Should we add OneLogin?
No - one enrolment feed per tenant. Two live feeds create duplicates and double-reminders. Keep the M365 sync and use OneLogin as the authoritative directory behind it, or switch the feed to OneLogin entirely.
One last thing
Audit the leaver path before the hire path. The new-starter gap shows up as a late enrolment; the leaver gap shows up in an audit - and audits cost more than late enrolments.