iPad Room
Display Security

Short answer: the four things to verify before approving any room display app: (1) credentials stored in hardware-backed storage (iOS Keychain), (2) calendar scopes limited to what's needed, (3) whether data transits the vendor's servers or goes device-to-API directly, and (4) physical lockdown (kiosk mode + locking mount). Get those four right and a hallway iPad is a low-risk device.

A wall-mounted iPad reading company calendars is exactly the kind of small purchase that lands on IT's desk for a security sign-off. Here's the actual review, in the order that matters.

1. Where do credentials live?

The credential (OAuth token or service-account key) should be stored in the iOS Keychain — hardware-backed, encrypted at rest, inaccessible to other apps. The Room Display stores credentials this way. Red flags in any app: credentials in plain files, in app preferences, or synced to a vendor cloud.

2. OAuth 2.0 vs service account — which should you use?

OAuth 2.0 (recommended default): the display authenticates as a dedicated user account you create (e.g. rooms@yourco.com). Access is visible in your admin console, revocable in one click, and auditable like any user. Give that account access only to room resources.

Service account with domain-wide delegation (Google) / app registration (Microsoft): better for fleet deployments — no interactive login per iPad, central key management. The discipline required: scope the delegation narrowly. Domain-wide delegation grants whatever scopes you authorize, so authorize only calendar scopes, never broad admin ones.

Either way, the principle is identical: the display gets its own identity, never a real employee's login.

3. Scope minimization

A room display needs to: read room calendars, create events on them, and list room resources. Concretely that means calendar read/write scopes plus resource directory read. It does not need: email scopes, Drive/SharePoint, user directory write, or admin scopes. If an app requests more than calendar + resource scopes, ask why before approving.

4. Where does the data flow?

The architecture question vendors hope you won't ask: does calendar data pass through the vendor's servers? Many platforms sync your calendar into their cloud (that's how their dashboards work). The Room Display talks directly from the iPad to Google/Microsoft APIs — meeting data never touches our infrastructure, because we don't have any in the data path. For a privacy review, that's the short version: there is no third party to assess.

5. Physical security checklist

• Locking enclosure — the iPad shouldn't leave with a visitor
• Guided Access or Single App Mode — no escaping to Settings or Safari (our kiosk guide)
• Meeting titles on the display: decide policy. Showing "Busy until 15:00" instead of "M&A discussion w/ Acme" is a one-toggle privacy choice worth making consciously for client-visible hallways
• Dedicated Wi-Fi/VLAN if your network policy segments IoT-class devices — the display only needs HTTPS egress to Google/Microsoft

FAQ

Can a stolen display iPad leak data? It holds a Keychain-stored credential scoped to room calendars. Revoke the account/key in your admin console and the device is inert. With Find My + Activation Lock enabled, it's also a brick.

Does the app need MDM? No, but MDM makes fleets nicer — see our ABM/MDM guide.

SSO support? The OAuth flow uses your normal Google/Microsoft sign-in — existing SSO and conditional-access policies apply to the rooms account like any user.

This post is written to be forwarded to the security reviewer as-is — it should answer their first six questions before the meeting.