⚠ NCSC: Week 18: Parcel phishing with a devious twist – The "double phishing" scam 🔴 CVE: CVE-2026-40393 (CVSS 8.1) — In Mesa before 25.3.6 and 26 before 26.0.1, out-of-bounds memory access can o… 📰 New article: The CISO Game in Chiasso: What a Simulated Cyber Crisis Teaches That No Presentation Ever Could ⚠ NCSC: Week 18: Parcel phishing with a devious twist – The "double phishing" scam 🔴 CVE: CVE-2026-40393 (CVSS 8.1) — In Mesa before 25.3.6 and 26 before 26.0.1, out-of-bounds memory access can o… 📰 New article: The CISO Game in Chiasso: What a Simulated Cyber Crisis Teaches That No Presentation Ever Could
← Back to articles
11 min read

Hardening Microsoft 365 for Swiss Organisations: A Practical Security Checklist

Swiss organisations running Microsoft 365 face a threat landscape shaped by BEC, quishing, and token-theft attacks. This checklist maps the CIS Microsoft 365 Foundations Benchmark and NCSC guidance to practical configuration steps — Conditional Access, Secure Score remediation, Exchange Online protection, and audit logging — with Swiss data residency considerations.

Microsoft 365 is the productivity backbone of the majority of Swiss SMEs, cantonal administrations, and large enterprises. It is also, by volume, the platform most frequently abused in the attacks the Swiss NCSC documents every quarter. Business email compromise (BEC) losses reported to the NCSC have increased year-on-year since 2022, driven almost entirely by compromised Microsoft 365 accounts. Quishing campaigns — QR-code phishing designed to bypass Secure Email Gateway scanning — now routinely target Swiss organisations specifically to harvest Entra ID credentials. And token-theft via adversary-in-the-middle (AiTM) proxies such as Evilginx and Tycoon 2FA has rendered SMS-based multi-factor authentication insufficient as a standalone control. The urgency is not theoretical: the combination of a high adoption rate and a historically low Secure Score across Swiss tenants creates systemic risk that attackers have already learned to exploit at scale. This checklist maps the CIS Microsoft 365 Foundations Benchmark v4.0 and NCSC hardening guidance to actionable configuration steps, with Swiss-specific notes on data residency under the revised Federal Act on Data Protection (nDSG).

1. Conditional Access — the Foundation

Conditional Access policies in Entra ID are the primary control plane for identity-based risk in Microsoft 365. Without them, the tenant's security posture depends entirely on per-user MFA settings and Security Defaults — neither of which provides the granular, risk-adaptive control that modern attacks require. The following policies represent the minimum viable baseline.

  • Require MFA for all users. Create a Conditional Access policy scoped to all users and all cloud applications that requires multi-factor authentication. Exclude only emergency access (break-glass) accounts from this policy. Configure the authentication strength to require phishing-resistant methods — FIDO2 security keys or Windows Hello for Business — for administrator roles. For standard users, Microsoft Authenticator with number matching is an acceptable interim position.
  • Require compliant or hybrid-joined device. Create a policy that requires the device to be marked compliant by Microsoft Intune, or hybrid-joined to on-premises Active Directory, as a condition of accessing corporate applications. This control directly counters token-theft attacks: even if an attacker obtains a valid session token from an AiTM proxy, they cannot satisfy the device compliance requirement from an unmanaged machine.
  • Block legacy authentication protocols. Create a policy that blocks all authentication flows using legacy protocols — ActiveSync, IMAP, POP3, SMTP AUTH — for all users. Legacy authentication cannot satisfy MFA challenges and is consistently exploited in credential stuffing and password spray campaigns. Verify that no service accounts or shared mailboxes depend on these protocols before enforcing the block; where they do, migrate them to OAuth-based authentication.
  • Named locations policy for Switzerland. Define Switzerland (and any other expected sign-in geographies) as a named location in Entra ID. Create a policy that requires MFA — or blocks access entirely — for sign-in attempts originating outside those named locations. This is a lightweight but effective control against credential stuffing from overseas infrastructure and provides a tunable threshold that Swiss organisations can adjust based on their remote-work footprint.
  • Sign-in risk policy via Entra ID Protection. If the tenant has Entra ID P2 licensing, enable the sign-in risk Conditional Access policy provided by Entra ID Protection. Configure it to require MFA re-authentication for medium-risk sign-ins and to block access for high-risk sign-ins. Entra ID Protection's risk signals include real-time intelligence on AiTM token theft, impossible travel, and leaked credential lists — controls that are otherwise unavailable at the policy layer.

2. Entra ID and Identity Hardening

Conditional Access policies operate on top of an identity foundation that must itself be hardened. Several default Entra ID configurations create unnecessary exposure for Swiss tenants that have not reviewed them since initial provisioning.

  • Disable Security Defaults if using Conditional Access. Security Defaults and Conditional Access are mutually exclusive control frameworks. Tenants that have deployed Conditional Access policies must disable Security Defaults — leaving both enabled causes unpredictable policy conflicts and false confidence. Navigate to Entra ID > Properties > Manage Security Defaults and disable the toggle. Verify that no existing policy relied on Security Defaults-enforced MFA before disabling.
  • Enable Privileged Identity Management for admin roles. Privileged Identity Management (PIM) converts permanent admin role assignments into time-bound, just-in-time activations with approval workflows and audit trails. For Swiss tenants, PIM is particularly important for Global Administrator, Exchange Administrator, and Compliance Administrator roles — the roles most frequently targeted in BEC follow-on attacks. Require justification and approval for all activations, and configure activation alerts to notify a security distribution list.
  • Review guest access settings. Entra ID's default guest access settings allow external users to enumerate directory membership and access a broad set of tenant resources. Navigate to Entra ID > External Identities > External Collaboration Settings and restrict guest user access to the most permissive setting appropriate for your organisation's collaboration model. For most Swiss organisations, guests should not be able to enumerate the directory or access resources beyond those explicitly shared with them.
  • Enable Entra ID Password Protection. Entra ID Password Protection maintains a dynamically updated list of globally banned passwords and allows tenants to add custom banned terms — including company names, product names, and Swiss geography terms that are predictably used in weak passwords. Enable it in Audit mode first to assess impact, then switch to Enforced mode. Extend the policy to on-premises Active Directory via the Password Protection agent if hybrid identity is in use.
  • Rotate emergency access account credentials. Break-glass accounts — permanent Global Administrator accounts excluded from Conditional Access policies — are the last resort for tenant recovery but represent a critical single point of failure if their credentials are compromised. Ensure these accounts use 60-character or longer randomly generated passwords, store credentials in a physical safe with access controls, and rotate credentials at least annually. Verify that audit alerts fire on any use of these accounts.

3. Exchange Online and Email Protection

Email remains the primary initial access vector in Swiss incidents documented by the NCSC. Exchange Online's default configuration provides a starting point, not a finished security posture. The following controls address the most consistently exploited gaps in Swiss tenant email configurations.

  • DMARC p=reject on your sending domain. DMARC at enforcement level (p=reject) instructs receiving mail servers to reject messages that claim to originate from your domain but fail SPF or DKIM validation. It is the primary technical control against domain impersonation in BEC and supplier fraud campaigns. Many Swiss organisations have published a DMARC record at p=none (monitoring only) and not advanced to enforcement. Verify your current policy at a DMARC lookup tool and progress to p=quarantine, then p=reject, after confirming that all legitimate sending services pass authentication.
  • DKIM enabled for your sending domain. DomainKeys Identified Mail (DKIM) adds a cryptographic signature to outbound mail that allows receiving servers to verify that the message was not modified in transit and originated from an authorised sender. Enable DKIM signing for your domain in the Microsoft 365 Defender portal under Email & Collaboration > Policies & Rules > Threat Policies > DKIM. Confirm that the CNAME records for the two DKIM selectors are published in your public DNS before enabling.
  • Enable Safe Links and Safe Attachments in Defender for Office 365. Safe Links rewrites URLs in emails and Office documents and checks them against Microsoft's threat intelligence at click time — a critical control for quishing and multi-stage phishing attacks that deliver malicious URLs through legitimate services. Safe Attachments detonates attachments in a sandboxed environment before delivery. Both require Defender for Office 365 Plan 1 licensing (included in Microsoft 365 Business Premium). Configure the built-in protection policy as a minimum and consider creating a custom strict policy for high-risk users such as finance and executive teams.
  • Block auto-forwarding to external domains. Automatic email forwarding to external addresses is consistently used by attackers who have compromised a mailbox to exfiltrate mail silently over an extended period. In Exchange Online, configure the outbound spam filter policy to set Automatic Forwarding to Off for all users. This is a single policy change that eliminates one of the most commonly observed post-compromise persistence mechanisms in Swiss BEC cases.
  • External sender warning banner. Configure Exchange Online mail flow rules to prepend a warning banner to all inbound messages that originate from outside your organisation. The banner should indicate clearly that the message is from an external sender and that the recipient should exercise caution before clicking links or opening attachments. While a human-layer control rather than a technical block, this warning has measurable impact on click rates in organisations that have deployed it consistently.

◆ Key Takeaway

Most Swiss Microsoft 365 tenants have a Microsoft Secure Score below 40% — a figure consistent with what the NCSC observes in incident investigations involving compromised M365 tenants. Implementing the Conditional Access baseline, the Exchange Online email protection controls, and the Entra ID identity hardening items in this checklist alone — without any additional investment — is sufficient to push a typical Swiss tenant's Secure Score above 65%. That delta represents the difference between a tenant that falls to opportunistic credential stuffing and one that forces attackers to expend substantially more effort and capability to gain a foothold.

4. Audit Logging and Incident Readiness

Detection and response capability depends entirely on the availability and retention of audit data. Swiss organisations that have not explicitly configured audit logging frequently discover, during an incident investigation, that the data needed to establish the scope and timeline of a compromise was never collected or was overwritten before it could be reviewed.

  • Enable the Unified Audit Log. The Unified Audit Log (UAL) captures activity across Exchange Online, SharePoint Online, OneDrive, Teams, Entra ID, and other Microsoft 365 services into a single searchable record. In newer tenants it is enabled by default, but in tenants provisioned before 2019 it may still be disabled. Verify the status in the Microsoft Purview compliance portal under Audit > Start recording user and admin activity. Enable it immediately if it is not already active.
  • Extend audit log retention to 180 days minimum. The default UAL retention period is 90 days for E3-licensed tenants and 180 days for E5-licensed tenants. BEC investigations consistently reveal that the initial compromise pre-dates detection by 60 to 120 days. Swiss organisations should extend retention to 180 days at minimum — requiring E5 licensing or the Microsoft Purview Audit (Premium) add-on — and consider 365-day retention for organisations subject to nDSG documentation obligations or sector-specific regulations such as FINMA circular requirements.
  • Configure alerts for high-risk activities. Create alert policies in the Microsoft Purview compliance portal for: impossible travel sign-in events; mass download or mass delete operations in SharePoint or OneDrive; mail forwarding rule creation to external addresses; and changes to Conditional Access policies. Route these alerts to a security distribution list or SIEM ingestion endpoint. Impossible travel alerts in particular have a high signal-to-noise ratio for Swiss organisations whose users are predominantly located in Switzerland.
  • Ensure admin audit logging is enabled. Exchange Online administrator audit logging records configuration changes made by administrators to the Exchange Online organisation. Verify that it is enabled by running Get-AdminAuditLogConfig in Exchange Online PowerShell and confirming that AdminAuditLogEnabled is set to True. Admin audit log data is essential for detecting post-compromise mailbox rule creation and delegated access changes during a BEC investigation.

5. Swiss Data Residency Considerations

Microsoft's European Union Data Boundary and the Swiss data boundary commitments introduced in 2023 are directly relevant to Swiss organisations assessing their nDSG compliance obligations and their contractual data processing commitments to customers.

By default, Microsoft 365 tenants provisioned with a Swiss billing address store core customer data — Exchange Online mailbox content, SharePoint Online files, Teams messages, and Entra ID directory data — in Microsoft's Swiss data centres in the canton of Geneva and the canton of Zurich. This default behaviour satisfies the nDSG's cross-border data transfer requirements for transfers within Switzerland and does not require a separate data transfer mechanism.

To verify where your tenant's data is stored, navigate to the Microsoft 365 Admin Center, select Settings > Org Settings > Organization Profile, and view the Data Location entry. This entry lists the geography in which each workload's data at rest is stored. Swiss tenants should confirm that Exchange Online, SharePoint Online, Teams, and Entra ID all show Switzerland or European Union as the data location — not the United States or another region, which can occur if the tenant was originally provisioned with a non-Swiss billing country and subsequently migrated.

Under the nDSG, organisations must be able to document where personal data is processed and stored. The Microsoft Products and Services Data Protection Addendum (DPA) and the Microsoft Trust Center's Data Residency documentation together constitute the primary evidence base for this documentation. Retain a copy of the relevant DPA version and the Admin Center data location screenshot as part of your nDSG records of processing activities (Verzeichnis der Bearbeitungstätigkeiten). If your organisation uses Microsoft 365 Copilot or other AI-powered features, verify separately that data used to train or ground those features is subject to the same residency commitments — Microsoft's commitments for AI features have evolved and are documented separately from the core workload commitments.

Prioritisation: Where to Start

For Swiss organisations beginning their M365 hardening journey with limited time and resources, the following three-priority ordering provides the highest risk reduction per unit of effort.

  • Priority 1 — Block legacy authentication and require MFA for all users. These two Conditional Access policies together eliminate the two most common initial access vectors in Swiss M365 incidents: password spray via legacy protocols and credential phishing where MFA is not required. Both can be deployed in Report-only mode to assess impact before enforcement, and both are feasible without additional licensing beyond Microsoft 365 Business Basic or above. Implement these first, before any other item on this checklist.
  • Priority 2 — Enable Safe Links, Safe Attachments, and block external auto-forwarding. The email protection controls address the second most common attack vector — phishing and quishing — and the most common post-compromise persistence mechanism. Safe Links and Safe Attachments require Defender for Office 365 Plan 1, which is included in Microsoft 365 Business Premium. Blocking external auto-forwarding requires no additional licensing and is a single policy change with no user-facing impact.
  • Priority 3 — Enable and extend audit logging, then configure alerting. Without audit data, every subsequent control improvement is unverifiable and every future incident investigation is severely hampered. Extend UAL retention and configure the four alert categories above before investing further in preventive controls. Detection capability compounds over time; audit data that is never collected cannot be retrospectively recovered.

The items beyond these three priorities — PIM, Entra ID Password Protection, DMARC enforcement, device compliance policies, and data residency verification — are not optional for mature organisations, but they can be sequenced across a 90-day implementation programme once the Priority 1 and Priority 2 controls are in place. The CIS Microsoft 365 Foundations Benchmark provides a scored checklist against which each implementation milestone can be measured, and Microsoft's Secure Score dashboard in the Microsoft Defender portal provides real-time feedback on configuration progress against the same control set.