Mobile security · Cloud computing · 3 min read
Securing Cloud and Mobile Access With One Identity Layer
Short answer
When users reach cloud apps from mobile devices anywhere, the network stops being a useful security boundary, so access decisions move to the identity provider: every sign-in is checked against the user's authentication strength, the device's state and the context, before short-lived tokens are issued.
Key takeaways
- Route every cloud and mobile app through one identity provider so policy is defined once.
- Combine phishing-resistant MFA with device signals from MDM or endpoint management.
- Keep tokens short-lived so policy changes and revocations take effect quickly.
A salesperson opens the CRM on a phone in an airport. A contractor reviews a document from a home laptop. Neither request touches the corporate network, and both reach sensitive data. Firewalls and VPNs cannot see them. What can see them is the identity provider that signs each user in, which is why identity has become the main control for cloud and mobile access.
Why does the network perimeter fail for cloud and mobile?
Because the user, the device and the application are all outside it.
Old access models assumed that being on the internal network meant being trusted. SaaS applications live on the public internet and mobile devices connect from anywhere, so that assumption covers almost nothing. NIST's zero trust architecture (SP 800-207) describes the replacement: evaluate each access request on its own merits, using identity and device information, every time.
What does a single identity layer look like?
One identity provider that every cloud app trusts for sign-in, applying the same policies for authentication strength, device state and context.
- Federate everything. Each SaaS app trusts the IdP through SAML or OpenID Connect. Native and mobile apps use OAuth with PKCE.
- Strong authentication. Phishing-resistant MFA (FIDO2 security keys, passkeys, platform authenticators) for everyone, and mandatory for administrators.
- Device signals. The IdP asks endpoint or mobile device management whether the device is enrolled, encrypted, patched and not jailbroken.
- Context. Location, network reputation, time and unusual behavior feed a risk score.
- Decision. Allow, require step-up authentication, allow with restrictions (for example browser-only, no downloads) or block.
- Short-lived tokens. Access tokens of minutes to an hour mean a changed decision takes effect soon.
How do device signals reach the identity provider?
Through integration between the IdP and device management, or through client certificates and platform attestations on managed devices.
| Signal | Source | Typical use |
|---|---|---|
| Enrolled and compliant | MDM / UEM | Allow full access to sensitive apps |
| Work profile present | Android Enterprise, Apple User Enrollment | BYOD with separation of work data |
| Device certificate | Managed PKI | Strong device identity, mTLS to gateways |
| OS version, jailbreak status | MDM, mobile threat defense | Block outdated or compromised devices |
| Unmanaged | None | Browser-only access, no offline data |
For personally owned devices, see our pieces on BYOD security and BYOD in Europe.
What about mobile apps that call APIs directly?
They should use OAuth 2.0 with PKCE in the system browser, so the same IdP policies apply when the app signs the user in.
When a native app opens the IdP's sign-in page in the system browser, conditional access and MFA run there, exactly as for web apps. The app then gets tokens limited by scope and lifetime. The native app article covers the details, and you can sketch the request in the Authorization URL Builder.
How do I roll this out without breaking work?
Start in report-only or audit mode, measure who would be blocked, fix the gaps, then enforce in stages.
Most identity providers let you run policies in a monitoring mode. Use it to find legacy protocols (IMAP, POP and SMTP basic authentication, old Exchange ActiveSync clients) that cannot do modern authentication, accounts without MFA, and devices that would fail compliance. Enforce for administrators first, then for sensitive applications, then broadly. Keep two break-glass accounts excluded from policy, with long random passwords stored offline and monitored for any use.
Questions
What is conditional access?
Conditional access is the general name for policies that grant, restrict or block a sign-in based on conditions such as user group, application, device compliance, location and risk. Microsoft uses it as a product feature name; other identity providers offer equivalents under different names.
Are passkeys suitable for workforce sign-in?
Yes, increasingly so. Device-bound passkeys and FIDO2 security keys are phishing-resistant, and major identity providers support them for employees. Plan for account recovery and for shared or kiosk devices.
Sources
Tagged: Mobile, Cloud, BYOD, Identity, Authentication, Mobile security