BYOD Architecture — CISO Decision Brief

To: Richard Williams (CISO)

From: Lucas Shin (Security Director)

Date: 2026-02-25

Purpose: Decisions required on BYOD architecture direction and residual risk acceptance

1. Why This Brief Exists

Our BYOD security architecture has a fundamental asymmetry between macOS and Windows due to how each OS handles personal device management. This asymmetry affects data protection mechanisms, user experience, and how we explain our security posture to auditors and clients.

This document distils the technical analysis into the decisions that require CISO sign-off before we can finalise the BYOD policy and procedures.

2. The Asymmetry — What You Need to Know

Why it exists

• Apple (macOS): Designed for BYOD. Account-Driven User Enrollment (ADUE) creates a separate encrypted volume (Managed Volume) that isolates all work data from personal data at the OS level.
• Microsoft (Windows): Designed for corporate-owned devices. No OS-level data isolation for BYOD. After WIP deprecation, the only BYOD protection is Intune App Protection Policies (APP) applied to Managed Edge — limiting access to web apps only.

What this means in practice

The core gap: macOS has file isolation but an open clipboard. Windows has clipboard control but no native apps.

Key security finding (validated 2026-02-23)

Concern that third-party apps could bypass macOS Managed Volume isolation has been resolved. Server-side Entra ID controls (Enterprise App Registration + Admin Consent Required + User Assignment) block unauthorised apps from obtaining M365 tokens entirely. This strengthens the security argument for the current macOS approach.

3. Architecture Options

Case 3 (both platforms native apps, no restrictions) was rejected — Windows native app access allows file downloads to the personal area with no isolation, enabling file-level data exfiltration.

Important nuance on "symmetry"

Even in Case 1, file download handling remains asymmetric: macOS allows downloads into the Managed Volume (isolated), while Windows must block downloads entirely (no isolation). Security outcome is equivalent (no file exfiltration either way), but user experience differs — macOS users can work with downloaded files locally, Windows users cannot.

Residual risks (Cases 1 & 2)

• R1 — Clipboard copy/paste (Case 2 only): Manual, per-instance. Low volume exfiltration risk.
• R2 — Screenshots (all cases): Cannot be blocked on desktop BYOD. Any data visible on screen can be captured.
• R1 vs R2 relationship: Even if copy/paste is blocked (Case 1), the same data is exfiltrable via screenshots. Eliminating R1 does not eliminate the underlying exposure — it only removes one of two channels for the same data.

4. Decision Required

Architecture Direction — Case 1 vs Case 2

Question: Which architecture should we adopt?

Recommendation: Case 2 (asymmetric) is the current direction.

• Leverages each platform's strengths — macOS volume isolation, Windows APP controls
• No additional cost
• ADUE server-side controls validated — security posture is strong
• R1 (clipboard) is low risk, and R2 (screenshot) exists regardless

Case 1 offers cleaner policy narrative but sacrifices macOS native app experience and requires MDA licensing. Defender for Cloud Apps (MDA) is not included in Business Premium — requires a standalone licence or Defender Suite add-on (~$10/user/month). MDA is only needed for BYOD under Case 1. (MDA may still be relevant for other use cases, but that is outside BYOD scope.)

If Case 2 — Copy/Paste Parity Approval Required

If Case 2 is selected, copy/paste is allowed on both platforms:

• macOS: Cannot block — OS limitation (residual risk R1)
• Windows: Blockable by APP but intentionally not applied — parity with macOS

Approve the following Windows BYOD (Managed Edge) APP settings:

SharePoint / OneDrive External Sharing — Restrict to Internal Only

What is this about?

When employees store files in Microsoft 365, those files live in two places:

• SharePoint (SPO) — team files, shared through Teams channels
• OneDrive (ODB) — personal work files, each person's own space

Both SPO and ODB have a setting that controls who employees can share files with. By default, Microsoft allows sharing with anyone outside the organisation — including creating links that don't even require a login.

What's the risk?

If external sharing is open, any employee can share any file with anyone outside the company by creating a sharing link from SharePoint or OneDrive — bypassing the Teams channel workflow where sharing is controlled by Team Owners.

This is not an issue today (all 3 current users are administrators), but becomes a real risk when non-admin members join.

What are the options?

How would external sharing still work?

If we choose "Only people in your organization", employees who need to share files externally can still:

1. Send as email attachment via Outlook (subject to Exchange DLP rules)
2. Invite a guest to a Teams channel (Team Owner approval required)

Both routes are tracked, auditable, and controlled by admin/owner permissions.

Recommendation: Set both SPO and ODB to "Only people in your organization"

• Closes the direct external sharing path entirely
• Forces all external collaboration through controlled channels (email or Teams guest invite)
• Can be relaxed to "Existing guests only" later if a specific business need arises
• No impact on current operations — all 3 current users are admins who can adjust settings if needed

Business Basic Users — Email Security Gap Assessment

What is this about?

When we set up email security controls (DLP rules, advanced threat protection), the tools available depend on the user's licence.

• Business Premium (BP) users get Purview DLP and Defender for Office 365 P1 included
• Business Basic (BB) users get neither — and there is no add-on path for DLP (the standalone AIP P1 licence was discontinued in January 2024)

This means BB users only have baseline protection (Exchange Online Protection — known malware, phishing, and spam filtering) and no DLP policy tips when sending emails containing sensitive information.

What's at stake?

Two capabilities that BP users will have but BB users will not:

Why does this matter now?

Today all 3 active users are on Business Premium, so this gap doesn't exist yet. However, when the team grows and some members are assigned BB licences (e.g. resource accounts or cost-optimised seats), those users will have weaker email security than BP users.

The long-term plan is to move all users to Business Premium when partner benefits are fully activated — but until then, BB users represent a known gap.

Decision required (2 items):

Windows Native App Access on BYOD — Not Permitted

Current position: Windows native desktop apps (Teams, Outlook, Office) are not permitted on BYOD under the current architecture. This applies regardless of Case 1 or Case 2 selection.

Why this is not a future option under current licensing:

One potential path to enabling Windows native apps would be Microsoft Purview Sensitivity Labels — if all Confidential data were labelled with encryption, local cache exposure from native apps would be mitigated. However, auto-labeling is not available on Business Premium:

Without auto-labeling, protection depends entirely on users manually applying labels — unlabelled data remains unencrypted in local cache (Teams: %AppData%\Microsoft\Teams, Outlook: OST cache file). Manual-only labeling cannot be relied upon as a security control.

Prerequisite for future reconsideration:

• Microsoft Purview Information Protection and Governance Add-on for Business Premium becomes available with auto-labeling support, OR
• Licence tier upgrade to E3/E5

Until either condition is met, Windows BYOD remains Edge-only (Managed Edge with APP). This is not a discretionary policy choice — it is a licensing-constrained architectural requirement.

5. References

• 🚧 BYOD Security Architecture — Platform Asymmetry Analysis (Backdata) — Full technical analysis
• [Domain Context] Security Architecture — §1.1, §1.5, §1.7, §3.6
• BYOD Security Policy — §7 Application & Data Governance
• BYOD Quick Reference — Platform User Guide — End-user facing summary