Migrating from KnowBe4 or SoSafe: A Cutover Runbook

Why are DACH teams migrating from KnowBe4 or SoSafe now?

Voice phishing attacks surged 442% between the first and second halves of 2024, according to the CrowdStrike 2025 Global Threat Report^[1]. Mandiant's M-Trends 2026 data points the same direction: voice phishing accounted for 11% of confirmed initial infection vectors in 2025 investigations and 23% of cloud-related compromises, while email phishing no longer ranks among the top observed initial intrusion vectors globally^[2]. The channel mix has changed faster than most awareness programs have.

The 2025 ShinyHunters campaign showed what that looks like in practice: attackers combined vishing and OAuth token theft to reach hundreds of downstream Salesforce customer organizations in a single operation^[3]. The entry point was a phone call to a help desk or a trusted integration, not a malformed attachment. An email-only click-rate program never tests the behavior that failed here.

The second driver is statutory. Since 6 December 2025, the revised BSI Act (BSIG) applies to roughly 29,000 German entities, and Section 30 names workforce security awareness against social engineering and phishing as a required risk management measure, with management bodies personally accountable under Section 38^[4]. For these entities, NIS2 makes continuous security awareness training a statutory duty rather than a best practice.

• Threat reality: attackers now open with voice, SMS, messenger, and deepfake video, so simulations on email alone measure the wrong behavior.
• Compliance pressure: BSIG Section 30 makes continuous, documented awareness a statutory duty, and auditors expect evidence of practical behavior rather than attendance certificates.
• Program fatigue: annual click-rate training has plateaued in many organizations, and leadership increasingly questions what it actually reduces.

What must a SoSafe alternative deliver before you commit?

Migration effort only pays off if it buys a capability jump. Before comparing pricing pages, hold every candidate against five criteria. If a vendor fails the first one, the rest of the checklist is decoration.

1. Multi-channel simulation across email, SMS, voice (vishing), messenger, and deepfake video. Attackers now open with channels far beyond email, so a replacement that only sends better emails reproduces the gap you are leaving.
2. OSINT-driven personalization and role-specific targeting instead of a static template library, so each simulation reflects the recipient's actual role, language, and attack surface.
3. German-language content and region-specific threat patterns, contextualized beyond a translated interface.
4. Sovereign hosting in Germany with GDPR-compliant data processing, so employee data stays under EU jurisdiction.
5. Works council readiness under Section 87(1) no. 6 BetrVG: group-level reporting anonymization with a minimum group size of 5, agreed with the Betriebsrat before the first campaign, not after.

Two of these deserve a hard look during the pilot. Voice and deepfake simulations require consent handling and callback-number management that many platforms have never operated at scale. Ask each candidate how it records consent for voice clones and how it restricts sender domains, and put both in your RFP.

For a side-by-side view of how the established DACH vendors score on these criteria, the 2026 platform comparison covers channel coverage, works council readiness, and data sovereignty in one matrix.

What carries over, and what must be rebuilt?

Set expectations before the project starts: most of what matters in an awareness program is behavioral history, and behavioral history rarely transfers between vendors. What does transfer is the identity layer and your aggregate baselines.

On the legal side, GDPR Article 20 gives data subjects the right to receive personal data they have provided in a structured, commonly used, machine-readable format and to transmit it to another controller^[5]. That right covers personal data, not the vendor's analytics: click rates, risk scores, and training histories are derived data, so there is no portability claim that forces the incumbent to hand over its data model. Export what the vendor offers as reports, archive it, and move on.

In practice, a fresh baseline is healthier anyway. Click rates measured against a static template library say little about how employees respond to a voice clone of your CFO. Run the first quarter in the new platform as a clean baseline, and compare reporting rate and incident rate from campaign two onward.

How do you plan the migration timeline?

A typical implementation runs three to four weeks from kickoff to the first live campaign. Most of the effort sits on the customer's IT side, in whitelisting and SCIM configuration, so the timeline depends on your team's availability more than on the vendor's.

• Weeks 1 to 2: admin access, user sync via SCIM or CSV, SSO setup. Confirm which SCIM attributes drive targeting (department, country, preferredLanguage) and that provisioning runs on the identity provider's regular sync cycle.
• Weeks 2 to 3: whitelisting of sending domains and simulation landing-page URLs as separate steps, reporting-button deployment, contextualization with logo, email signature, and voice clone consent.
• Weeks 3 to 4: friendly-user test with a small group, then the first live campaign.

Sequence the procurement clock against this window. Start the runbook 60 to 90 days before the incumbent contract renews, so the parallel-run period fits inside your notice period and you are never paying for two platforms without using one of them. If the renewal date is closer than that, negotiate a one-month extension rather than compressing the pilot; a skipped friendly-user test is how a first campaign lands in spam folders across the company.

Sync cadence matters for planning: scheduled SCIM synchronization typically runs every 20 to 60 minutes depending on the identity provider, so account for that lag when you validate the roster before the first send^[6].

How do you run the SSO and SCIM cutover without lockout?

SCIM and SSO do different jobs: SSO authenticates users, while SCIM provisions and updates their accounts^[6]. Cut them over separately, provisioning first and authentication last.

1. Build the new SCIM enterprise application in Entra ID while the old platform's app still runs. Verify attribute mappings before assigning users; custom fields need explicit SCIM URN paths, and standard fields such as Company or Business Unit use enterprise schema extensions.
2. Exclude test and service accounts from provisioning scope, and confirm the first sync creates the expected user count with no duplicates.
3. Check that the SAML attribute mapping includes the role claim and that the correct groups are assigned in the Entra ID enterprise application. A missing role claim is the classic cause of the 'no role assigned' error after switching to SAML SSO.
4. Switch SAML SSO last, and keep at least one break-glass admin who can sign in without SSO. If the role claim is wrong, that account is your way back in.
5. Define rollback points in writing: after SCIM sync validation, after SSO switchover, and after the first campaign. Each needs a documented way back to the incumbent console, and the SSO switchover should stay reversible for 24 to 48 hours.

The Entra ID side of this is standard integration work; the Entra ID integration checklist covers SCIM provisioning, Defender allowlisting, and message injection in one place. The one non-standard trap: if the incumbent's SCIM app and the new platform's app provision the same users, deactivate the old app only after the new sync is verified, or the two provisioning engines will fight over attribute values.

How do you sequence the first campaign with no employee gap?

The go-live sequence is deliberately boring: validate on a small group, expand, and only then automate.

1. Friendly-user group first: typically 10 to 50 people from IT and security who expect simulations and will report false positives rather than escalate them.
2. Pilot campaign of one to two weeks with two to three templates. Validate delivery, language, and context before anything org-wide.
3. Org-wide rollout through the platform's automated campaign playlist, activated only after the pilot passes.
4. Keep the incumbent live in parallel until the pilot validates. Then decommission its SCIM app first and its SSO connection second, in that order, so authentication never outlives provisioning.
5. Archive the exported baseline reports before the incumbent tenant closes; audit continuity under NIS-2 depends on being able to show the history as well as the current state.

Voice and messenger scenarios deserve their place in that first rollout: interactive attacks resist automated technical controls in ways email lures do not, which is exactly the behavior a pilot should measure. Once the playlist runs, the measurement side takes over: one-click reporting in Outlook, Gmail, and mobile turns employees into an active detection layer, and the resulting interaction and incident data feeds audit-ready reporting. From this point the program tracks behavioral metrics such as reporting rate continuously.

One next action this week: map your incumbent's renewal date against the three-to-four-week runbook above and book the friendly-user group. If you want a platform assessment against the criteria in this runbook, we at revel8 run exactly this cutover with DACH security teams and can walk your IT leads through the SCIM and SSO sequence before you sign anything.

Sources

1. CrowdStrike 2025 Global Threat Report: Beware the Enterprising Adversary, crowdstrike.com
2. M-Trends 2026 reveals threat landscape shaped by faster, coordinated, and industrialized cyberattacks, industrialcyber.co
3. ShinyHunters Threat Actor Profile: TTPs, IoCs & Attacks, huntress.com
4. NIS2, ISO 27001, BSI Grundschutz: Awareness Requirements, revel8.ai
5. Art. 20 GDPR – Right to data portability - General Data Protection Regulation (GDPR), gdpr-info.eu
6. What Is SCIM? SCIM Provisioning Explained, authgear.com