Security exclusions represent one of the most nuanced decisions admins face when designing effective security policies. These exceptions to your standard security rules require careful consideration - apply them too liberally, and you risk creating security gaps; too restrictively, and you might impede legitimate work. But before you can determine how many exclusions to implement, you need to decide what type of exclusions make the most sense for your environment.
It's a question that generates strong opinions among IT/security teams, and for good reason. The approach you choose significantly impacts both security posture and user experience. Let's explore this decision point and provide a framework for determining which approach makes the most sense for your specific circumstances.
Understanding the Two Approaches
Before diving into the decision-making process, let’s clarify what we mean by these two types of exclusions:
User-Based Exclusions are security exceptions tied to specific user identities, roles, or groups. These exclusions follow the person regardless of which device they’re using. For example, you might exempt your design team from restrictions on certain creative applications, or grant your developers exceptions to run local development environments.
Device-Based Exclusions apply to specific devices regardless of who’s using them. These might be based on device type, ownership model, or security posture. For instance, you might exempt kiosk devices from screen lock requirements or create different security profiles for corporate-owned versus personal devices.
The distinction seems straightforward on the surface, but the implications run deep. Richard Hiralal, System Engineer at Grammarly, gave his opinion recently on the Patch Me If You Can podcast saying, "I honestly think it depends on the situation, the control and also what your security team is okay with." This contextual approach is key since there’s rarely a one-size-fits-all answer.
Key Factors in Your Decision
When deciding between user and device-based exclusions, several factors should influence your approach:
The Nature of the Security Control
Some security controls naturally align better with one approach:
- User-centric controls like access permissions, application restrictions, and content filtering often make more sense as user-based exclusions since they’re directly tied to job functions and responsibilities.
- Device-centric controls such as firmware passwords, boot protections, or hardware-specific configurations typically work better as device-based exclusions since they’re inherently tied to the physical device.
Your Management Model
Your device ownership and management approach significantly impacts which exclusion type makes more sense:
- In a corporate-owned, single-user environment, the lines between user and device exclusions often blur since there’s a one-to-one relationship between users and their devices.
- In BYOD environments, user-based exclusions often provide more flexibility, allowing consistent policy application regardless of which personal device an employee might use.
- For shared device scenarios (like kiosks, lab computers, or shift-based workstations), device-based exclusions typically offer more straightforward management since multiple users access the same hardware.
Administrative Overhead
Consider the practical aspects of maintaining your exclusions over time:
- User-based exclusions typically require integration with identity management systems and can become complex as organizational structures evolve.
- Device-based exclusions may be simpler to implement initially but can become unwieldy as your device inventory grows and diversifies.
Use Cases for User-Based Exclusions
User-based exclusions are especially effective in several common scenarios:
Role-Based Requirements
When certain job functions require exceptions to security policies, user-based exclusions allow you to tie these exceptions directly to roles rather than devices. This works particularly well for:
- Executive staff who may need broader access privileges
- Creative professionals requiring specialized software
- Developers needing local admin rights or testing environments
- IT staff requiring elevated privileges for troubleshooting
Contextual Access Needs
User-based exclusions excel when access requirements change based on context:
- Remote workers who need different security configurations when working off-site
- Contractors who require temporary access to specific resources
- Employees who travel between different regulatory jurisdictions
Consistent Multi-Device Experiences
For users who regularly switch between devices, user-based exclusions provide consistency:
- Employees who use both laptops and tablets
- Staff who occasionally work from home on personal devices
- Team members who rotate between shared workstations
Use Cases for Device-Based Exclusions
Device-based exclusions offer advantages in other common scenarios:
Hardware-Specific Requirements
When exceptions are tied to device capabilities or limitations:
- Legacy devices that can’t support the latest security controls
- Specialized hardware with unique security requirements
- Devices with different operating systems or platforms
Location or Function-Specific Devices
When the device’s purpose or location dictates security needs:
- Kiosks or point-of-sale systems
- Conference room displays
- Lab or manufacturing floor devices
- Devices in high-security physical locations
Ownership-Based Policies
When device ownership determines appropriate security levels:
- Corporate-owned vs. personal devices
- Fully-managed vs. user-enrolled devices
- Temporary or loaner equipment
Pros and Cons Breakdown
To help visualize the trade-offs, consider this comparison:
User-Based Exclusions | Device-Based Exclusions |
Pros: | Pros: |
|
|
|
|
|
|
|
|
Cons: | Cons: |
|
|
|
|
|
|
|
|
Finding Middle Ground: Hybrid Approaches
Many organizations find that a hybrid approach provides the benefits of both approaches. Consider these strategies:
Layered Exclusions
Apply baseline exclusions at the device level, then add user-specific exceptions for special cases. This works well when you have a relatively standardized device fleet but diverse user needs.
Context-Aware Policies
Implement systems that consider both user identity and device characteristics when applying exclusions. This approach is more sophisticated but offers greater flexibility.
Segmented Management
Use device-based exclusions for some controls and user-based for others, depending on which makes more sense for each specific security requirement.
Decision-Making Flowchart
When determining which approach to use, this simplified decision path may help:
- Start by asking: Is this exception primarily about who needs access or what device needs special handling?
- If user-focused: Will this user need the same exception across multiple devices? If yes, lean toward user-based exclusions.
- If device-focused: Will multiple users of this device need the same exception? If yes, lean toward device-based exclusions.
- Consider maintenance: Which approach will be easier to maintain as your organization evolves?
- Evaluate risk: Which approach introduces less security risk for this particular control?
Conclusion: Making the Decision Work for You
The choice between user and device-based exclusions isn't about finding the "right" answer - it's about building a framework that balances security with productivity in your specific environment.
Focus on implementation, not ideology. The most successful security teams spend less time debating which approach is theoretically better and more time ensuring their chosen approach actually works in practice. This means:
- Start small and iterate. Pick one security control, implement exclusions using your chosen approach, and see how it performs over 30-60 days.
- Measure what matters. Track both security incidents and user friction. If your exclusions are creating help desk tickets or workarounds, they're not working regardless of how "correct" they are on paper.
- Build for change. Your organization will evolve, new devices will emerge, and roles will shift. Choose the approach that's easier for your team to modify when (not if) requirements change.
The real win isn't picking the perfect approach - it's being intentional about your choices. Document why you chose user-based for some controls and device-based for others. This creates consistency in your decision-making and makes future exclusions easier to evaluate.
Most importantly, remember that security exclusions should enable work, not create new friction. Whether you go user-based, device-based, or hybrid, the measure of success is simple: are your people more productive while your organization stays secure?