Events & community · Mobile security · 3 min read
Running a BYOD Security Workshop for Your Team
Short answer
A useful BYOD workshop brings identity, device management, security, HR and privacy people together for half a day, walks through real access scenarios, agrees device tiers and policies in the room, and ends with owners and dates for each gap.
Key takeaways
- Invite the people who own the decisions, not just the technical admins.
- Work through concrete scenarios: a new hire, a lost phone, a contractor, a leaver.
- Leave with written decisions, owners and dates.
BYOD decisions cut across teams. Security wants control, HR wants a clear policy, the privacy officer wants proportionality, and staff want their phones to keep working. A focused workshop gets those people to agree on one approach. Here is a plan you can reuse, from invitations to follow-up.
Who should be in the room?
The people who own each decision: identity, device management, security, HR, privacy or legal, and a business representative.
| Role | Why they are needed |
|---|---|
| Identity provider admin | Conditional access, MFA, sessions |
| Device management admin | Work profiles, app protection, compliance |
| Security lead | Risk appetite, incident response |
| HR | Policy, onboarding and offboarding, allowances |
| Privacy / legal | GDPR and labor law limits on monitoring |
| Business representative | What people actually need on their phones |
Keep it under a dozen people. Send the BYOD security checklist a week before.
What should the agenda look like?
Context, scenarios, decisions, then actions.
- 20 minutes: where we are. Survey results on devices and apps in use; current sign-in methods; any recent incidents.
- 60 minutes: scenarios. Walk each one end to end (see below).
- 15 minutes: break.
- 45 minutes: decisions. Device tiers, MFA methods, what gets wiped, token lifetimes, the policy text.
- 30 minutes: actions. Every gap gets an owner and a date.
- 10 minutes: communication plan. What employees will be told and when.
Which scenarios work best?
Short, specific stories that force a decision.
- New hire, day one. She wants email on her own Android phone. What does she install, what does she see, how long does it take?
- Lost phone. A manager's personal iPhone is lost abroad on a Friday night. Who can act, and what is removed?
- Contractor. A consultant with their own laptop needs two apps for three months.
- Leaver. An engineer resigns and leaves today. Which sessions and tokens still work tomorrow?
- Phishing. A user approves a fake MFA prompt from a phone. What stops the attacker?
For each, trace the sign-in: which identity provider policy applies, what the device must prove, what token is issued and for how long. If people want to see what a mobile sign-in request contains, show it in the Authorization URL Builder.
What decisions should come out of it?
A written list that can go straight into policy and configuration.
- Device tiers and what each may access.
- Allowed MFA methods, and a plan to retire weak ones.
- Selective wipe rules.
- Session and token lifetimes per tier.
- Offboarding steps and their owner.
- The employee-facing privacy statement.
What are the common traps?
Spending the whole session on device features, and leaving without decisions.
Device management consoles have hundreds of settings, and it is tempting to walk through them one by one. Keep the conversation at the level of outcomes ("work email on personal phones, no copy to personal apps") and let admins translate that into settings later. Another trap is designing for the most cautious possible policy and then watching people work around it with personal email. A useful test for every rule: would the business representative in the room accept it for their own team?
Finally, write down what you decided not to do, and why. Next year someone will ask why you did not require full device enrollment, and the answer will be in the notes.
What happens afterwards?
Send the decisions within two days, schedule the technical work, and review progress in a month.
A short, dated summary keeps momentum. Most of the technical changes are in the identity provider and device management console, and many can be tested in report-only mode first. For the technical background, see the mobile security guide.
Questions
How long should a BYOD workshop be?
Half a day works for most organizations: long enough to work through scenarios and decide, short enough that decision makers attend. Follow up with smaller technical sessions.
Should employees be involved?
Yes, at least through a short survey before the workshop about which devices and apps people actually use, and through employee representatives where national rules require consultation.
Sources
Tagged: BYOD, Event, Events, Mobile security