A phishing simulation platform is, by design, a system that can send convincing phishing to every employee with your email filters told to let it through, so a compromised admin account turns it into the most effective real phishing tool you own. Modern awareness platforms also hold a directory copy of the workforce, per-person click and risk scores, and often mailbox permissions to read reported messages or place lessons directly into inboxes. Programme teams naturally focus on content, cadence and culture; this vendor-neutral guide covers the platform itself: admin roles, campaign approval, mail and directory integrations, simulation infrastructure, people data and logging. It is for awareness managers, messaging engineers and security operations teams. For running simulations well see the Phishing Simulation Programme Guide; for selecting a platform see the Security Awareness Training Buyer's Guide.
Key takeaways
- Campaign creation is a privileged action. Whoever can create a campaign can send mail that bypasses filtering to the whole organisation, so campaign launch needs approval and admin accounts need strong protection.
- Mailbox integrations carry workforce-wide reach. OAuth apps that read reported mail or inject messages can usually touch every mailbox in the tenant.
- Simulation infrastructure must stay yours. Allowlisted sending domains, landing page domains and tracking links are trusted paths; if they lapse or are shared, others can use that trust.
- Risk scores are personal data. Per-person click history and risk ratings need purpose limits, access controls and retention, and they should not drive automatic discipline.
- Logs belong outside the platform. Campaign, role, integration and export events should reach a SIEM the awareness team cannot edit.
What makes up the platform's attack surface
| Component | What it holds or does | Privileged identities involved | Primary hardening |
|---|---|---|---|
| Campaign engine | Templates, target lists, send schedules | Campaign administrators, API clients | Approval before launch, template review, send volume alerts |
| Sending and landing infrastructure | Sending domains, IPs, landing pages, tracking links | DNS administrators, platform operators | Domain ownership tracked, allowlist entries scoped and reviewed |
| Mailbox integration | Reads reported mail, injects simulations or lessons, removes messages | OAuth app or service account with mail permissions | Least permission, scoped to mailboxes where supported, owner assigned |
| Directory sync | Users, groups, managers, departments | SCIM bearer token or directory read account | Read only, attribute minimised, token rotated |
| Learning content and LMS link | Courses, completions, certificates | LMS API keys, SSO trust | SSO with MFA, scoped API keys |
| Reporting and risk data | Clicks, submissions, reports, risk scores | Report viewers, HR integrations | Role scoped access, export controls, retention |
| Report button add-in | Lets staff report suspicious mail | Add-in deployment rights, backend API key | Centrally deployed, backend key server side |
Relevant ATT&CK techniques include T1078 Valid Accounts and T1098 Account Manipulation for admin takeover, T1528 Steal Application Access Token and T1550.001 Application Access Token for the mailbox integration, T1114 Email Collection for abuse of reported-mail access, and T1199 Trusted Relationship where a provider's access is the path in.
Administrative roles and campaign approval
NIST SP 800-53 AC-5 (separation of duties) and AC-6(5) (privileged accounts) set the goal: no single person should be able to design a lure, target it at chosen people, send it and hide the results.
| Role | Can do | Should not be able to do |
|---|---|---|
| Platform administrator | SSO, integrations, users, domains | Launch campaigns alone |
| Campaign author | Build templates, landing pages and target groups | Approve and launch their own campaigns |
| Campaign approver | Review content, targets and timing, then launch | Edit content after approval without re-approval |
| Report viewer | Aggregate results for their area | See named individual results outside their remit, export in bulk |
| Auditor | Read logs and campaign history | Change anything |
- Admin authentication: SSO with phishing-resistant MFA (IA-2(1)) for every admin, and the local owner account vaulted for break-glass. A platform built to phish should never itself be protected only by a password.
- Approval content: NHI Mgmt Group recommends that approvers check the sending domain, the landing page domain, the target list size and any group that is excluded or singled out, such as executives or HR.
- Targeting abuse: alert on campaigns aimed at one or a handful of named people, outside normal hours, or using templates that impersonate internal executives or payroll.
- Ethics and HR: the NCSC warns that punishing staff for clicking on simulations "starts to resemble entrapment" and advises checking with HR first. Build that into approval, not just policy.
Mailbox and directory integrations
Integration credentials are non-human identities with workforce-wide reach. Manage them under IA-9 (service identification and authentication) and IA-5 (authenticator management).
| Integration | Typical permission | Risk if misused | Control |
|---|---|---|---|
| Reported mail analysis | Read mail in reporting mailbox or all mailboxes | Bulk mail access | Scope to the reporting mailbox where the mail platform allows it |
| Direct inbox injection | Write to all mailboxes | Planting real lures that never cross the gateway | Only if needed, monitored, owner assigned |
| Message removal after reporting | Search and delete across mailboxes | Evidence destruction, data loss | Approval workflow, logged deletions |
| Directory sync | Read users and groups, or SCIM provisioning | Workforce enumeration | Read only, minimal attributes, token rotated |
| LMS and HR feeds | API keys | Training records altered, data leakage | Scoped keys, rotation, IP restriction |
- Review consent grants: record every permission each OAuth app holds and recheck after platform updates, which sometimes request new scopes. See the SaaS and OAuth App Governance Guide.
- SCIM tokens: long-lived bearer tokens are common; store them in a secrets manager and rotate on a schedule and when admins leave. See the SCIM Provisioning Guide.
- Owner per integration: each app registration and service account should have a named owner outside the awareness team as well as within it.
Simulation infrastructure
- Allowlisting scope: allow simulations through filtering using dedicated domains and IPs only, never shared infrastructure, as explained in the Phishing Simulation Programme Guide. Review the allowlist whenever the provider's infrastructure changes.
- Domain lifecycle: keep an inventory of every simulation and landing page domain you registered, with renewal dates. A lapsed domain that is still allowlisted gives its next owner a trusted route into your inboxes.
- Credential capture pages: configure landing pages so that entered passwords are not stored or transmitted, only the fact that a submission happened. Confirm this in testing with a dummy account.
- Tracking links: ensure links in simulations cannot be repurposed as open redirects to arbitrary sites.
People data and privacy
- Purpose limitation: define what risk scores are used for (targeted training) and what they are not (automatic disciplinary action). The NCSC recommends measuring reporting as well as clicks.
- Access: named individual results visible only to the awareness team and, where agreed, line managers for their own staff.
- Retention: NHI Mgmt Group suggests keeping named individual results for no longer than 24 months and aggregate trends longer (SI-12), subject to your privacy assessment.
- Data protection assessment: a DPIA or equivalent should cover monitoring, profiling and any HR integration.
Logging and monitoring
Forward platform logs to a SIEM the awareness team cannot alter (AU-9). Priority events:
- Campaign creation, approval, launch and edits after approval, with target counts.
- Role grants, SSO changes, new API keys and new or changed integrations.
- Bulk exports of individual results and changes to log forwarding.
- In the mail platform: sign-ins and mail actions by the integration app, and changes to the simulation allowlist.
See the SIEM Guide.
Hardening an existing platform: a phased approach
- Inventory (weeks 1 to 2): list admins, roles, integrations and their permissions, API keys, SCIM tokens, sending and landing domains and allowlist entries.
- Admin and approval (weeks 2 to 4): SSO with MFA, split author and approver roles, approval before launch. Pilot with one campaign; keep the previous role mapping documented for rollback.
- Integrations (weeks 3 to 6): reduce mailbox permissions to what each feature needs, remove unused integrations and rotate tokens and keys.
- Infrastructure (weeks 4 to 8): reconcile domains and allowlist entries, remove anything unused and set renewal alerts.
- Data and logs (weeks 6 to 10): set access scopes and retention for individual results and forward logs with alerts.
Timings are NHI Mgmt Group recommendations.
Decision guidance
- Inbox injection or delivery through the gateway: injection avoids allowlisting but needs write access to every mailbox; gateway delivery needs scoped allowlisting but keeps mailbox permissions smaller. Choose based on which risk your team can monitor better.
- Automated message removal: valuable for incident response, but give it approval steps and logging, or run it from your security operations tooling instead.
- Small organisations: with one awareness owner, have a security or IT lead approve each campaign by email or ticket and review the platform log monthly.
Detection and measurement
- Approval coverage: percentage of campaigns launched with an independent approval.
- Integration permissions: number of integrations with tenant-wide mail write or delete rights.
- Domain hygiene: allowlisted domains and IPs with no current owner or expired registration (target zero).
- Admin coverage: percentage of admins on SSO with phishing-resistant MFA.
- Token age: days since rotation of SCIM tokens and API keys.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 |
|---|---|---|
| Roles and campaign approval | AC-2(7), AC-5, AC-6(5) | PR.AA-05 |
| Admin authentication | IA-2(1) | PR.AA-03 |
| Mailbox and directory integrations | IA-5, IA-9 | PR.AA-01 |
| Awareness programme | AT-2 | PR.AT-01 |
| People data and retention | PT-2, SI-12 | PR.DS-01 |
| Provider and supply chain | SA-9 | GV.SC-05 |
| Logging and review | AU-6, AU-9, AU-12, AC-6(9) | PR.PS-04, DE.CM-03 |
Common failure patterns
- Password-only admin login: the phishing platform's own console is protected by a reused password.
- Everyone can launch: any awareness team member can send a campaign to the whole company without review.
- Over-scoped mail app: an integration holds read, write and delete on all mailboxes for a feature nobody uses.
- Stale allowlists: old simulation domains and provider IP ranges remain trusted after a platform change.
- Click scores in HR files: individual results flow into performance processes without an agreed purpose.
Practitioner checklist
- Protect every admin with SSO and phishing-resistant MFA, and vault the local owner account.
- Separate campaign authors from approvers and require approval before launch.
- Alert on narrowly targeted or executive-impersonation campaigns.
- Reduce mailbox and directory permissions to what each feature needs, with an owner per integration.
- Rotate SCIM tokens and API keys and store them in a secrets manager.
- Inventory and renew simulation domains, and review allowlist entries after any change.
- Confirm landing pages never store entered passwords.
- Limit access to and retention of individual results.
- Forward platform and integration logs to a SIEM.
Standards and references
- NCSC: Phishing attacks, defending your organisation
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Steal Application Access Token
- MITRE ATT&CK: Email Collection
- NCSC: Secure system administration
Related NHI Mgmt Group resources: Phishing Simulation Programme Guide · Security Awareness and Human Risk Management Guide · Security Awareness Training RFP Template · Securing the PAM Vault Itself