Network Domain Policies from Universities and Employers – Conflicts on Personal & DSA Devices

Network Domain Policies from Universities and Employers – Conflicts on Personal & DSA Devices

Modern users—particularly students and staff—often sign into multiple managed environments on a single device.

These can conflict, install along with software, EG: Office and Onedrive, Claro or Everway software, some other software.
University accounts, Employer accounts, Personal accounts, DSA-provided equipment or software (partially managed, accessibility-focused)

Each of these can apply device-level restrictions, which may conflict, overlap, or degrade system usability, especially on:

  • Personal laptops used for work/study
  • DSA-funded devices intended to remain flexible for assistive use

What Are Domain / Device Policies?

1. University Policies

Typically applied when a user:

  • Logs into Office 365 with a university account
  • Enrols in device management (Intune / MDM)
  • Downloads institution software (e.g. Teams, OneDrive, VPN)

Common controls:

  • Device compliance enforcement, read force password changes (encryption, antivirus)
  • Mandatory PIN/password complexity rules, read no simple passwords
  • Restricted admin rights, read cannot install anything/access camera etc.
  • Software installation policies
  • Conditional access (blocking apps or services unless device is “compliant”), read again, Camera or Mic not working with teams/zoom.

2. Employer Policies

Applied via:

  • Corporate MDM (Intune, JAMF, etc.)
  • Domain join (Active Directory)
  • VPN or endpoint security tools

Common controls:

  • Full device control (especially if domain-joined)
  • Blocking unsigned or unknown software
  • Restricted browser usage / extensions
  • Forced updates and remote wipe capability
  • Logging/monitoring
  • Blocking software IP and activation servers

3. DSA (Disabled Students’ Allowance) Context

DSA devices are typically:

  • User-owned, not centrally managed
  • Configured for assistive software flexibility
  • Intended to allow:
    • Microphone access (speech recognition)
    • Screen reading tools
    • Custom scripts/macros
    • Offline usage scenarios

This creates an inherent tension with locked-down enterprise policies.

Policy Stacking and Conflicts

When multiple organisations apply policies to one device, the result is often:

Conflicting Rules

  • University requires OneDrive sync → Employer blocks sync clients
  • Employer enforces BitLocker key storage → University requires its own compliance channel
  • Assistive software needs admin rights → One or both orgs remove admin privileges

Overlapping Security Enforcement

  • Multiple encryption/compliance checks
  • Duplicate endpoint security tools (performance impact)
  • Conditional access failures due to “non-compliant” status
  • Excessive use of system resources as some apps/services are doubled or conflict
  • Overheating
  • Restricted device access, camera, microphone etc

Functional Breakdowns

Users may experience:

  • Software failing to install or launch
  • Microphone or accessibility tools blocked
  • Updates breaking assistive tech compatibility
  • One account locking out another (e.g. “your org requires this device to be managed”)
  • Unknown or bad passwords

Real-World Conflict Scenarios

Scenario 1: University + Personal Device

A student signs into their university account on a personal laptop:

Outcome:

  • Device is silently enrolled into Intune
  • Local admin rights restricted
  • Assistive software install blocked
  • Microphone, Camera or other device access blocked
  • Enforced security/password policeis, cannot be applied but must be applied. resulting in a login loop/no access to device.

Scenario 2: Employer + University (Same Device)

A working student uses one laptop for both:

Outcome:

  • Employer requires device encryption and monitoring
  • University flags device as “non-compliant”
  • Access blocked to university resources (Teams, OneDrive)

Scenario 3: Employer + DSA Laptop (High Risk Case)

A user signs their work account into a DSA laptop

Outcome:

  • Employer policies override system settings
  • Assistive tools break (Dragon, Claro, JAWS, etc.)
  • Microphone/device access restricted
  • Potential breach of DSA expectations (device no longer “user-controlled”)

Scenario 4: Multiple MDM Enrolments

Some systems allow co-management but many don’t.

Result:

  • Device stuck in compliance loop
  • “This device is managed by another organisation” errors
  • Loss of access to both environments

Specific Risks for Assistive Technology Users

Given your environment, these are critical:

🎙 Speech Recognition (e.g. Dragon)

  • Requires persistent microphone access
  • Can be blocked by security/privacy policies

👁 Screen Readers (JAWS, NVDA)

  • May require elevated permissions
  • Can be flagged as “suspicious behaviour”

🧠 Productivity Tools (MindView, Claro, Texthelp)

  • Plugin restrictions (Office / browser lockdown)
  • Network restrictions (licensing failures)

Why This Happens (Technical Causes)

  • Group Policy / MDM precedence conflicts
  • Conditional Access tied to device compliance
  • Device identity tied to multiple tenants
  • Security baselines overriding user permissions
  • Zero Trust implementations interfering with local workflows

Best Practice and best fixes and prevention

1. Clear Device Use Policy

Provide users with simple rules:

  • Do NOT sign work accounts into DSA devices
  • Use:
    • Browser-only access where possible
    • Separate devices for employer use

2. Recommend Separation of Environments

3. Best defense against issues occuring.

Signing into apps like Onedrive, Office, Teams, Uni Wifi, Outlook or other Uni/Work software or systems can enrol your device automatically into organisational management.

In theory, if correctly configured, there should be a notification/the ability to only install/download a software, or use a service with the ability to then "opt out" of domain policies/security. In practice, this is often not the case or unclear.


Install your own personal email/account first, then create a new user for each subsequent use case, Uni, then work.

In most instances, this should leave the personal account as administrator/leave the ability to use that account as normal if any issues occur.

4. Other, less ideal Workarounds

  • Use web apps/sign in only (Teams Online, Outlook Web)
  • Avoid “Allow organisation to manage this device” prompts
  • Use local accounts for DSA setups where possible
  • Use separate browser profiles, or even browsers for each account/use case.

5. Known Conflicts

By no means a complete list, but the most common are:


If you sign your work or university account into your personal or DSA laptop, your organisation may automatically apply security policies that can restrict software, limit accessibility features, or prevent your assistive tools from functioning correctly.

To avoid issues, we strongly recommend using separate devices for work and study and avoiding organisation-managed sign-ins on your primary accessibility device.

In the common event that these policies cause an issue we cannot fix/we are unable to access or change those policies, we can only help by wiping, starting again and recommending the above.

Key Takeaways

  • Multiple organisations = multiple competing policies
  • Policies are designed for security, not accessibility, AT software is designed for accessibility, not security
  • DSA devices are especially vulnerable to disruption
  • Separation of environments is the single most effective mitigation