跳到主要內容

082: Review security, compliance, resource access requirements (Certs/Wi-Fi/VPN)

Implementation Effort: High
User Impact: Medium

Overview​

Certificate, Wi-Fi, and VPN profiles should not be designed independently. On mobile devices, these controls are tightly linked to enrollment mode, certificate issuance, network architecture, and the Conditional Access policies that determine whether the device is trusted for resource access. From a Zero Trust perspective, the goal is to grant the smallest secure network access required while using strong identity, device health, and certificate-based authentication where appropriate. That usually means planning prerequisites before building any single profile.

Implementation Guidance​

  1. Start with identity and access requirements: which resources are public SaaS, which are private, which require compliant devices, and whether app protection-only users need a different experience than enrolled users.
  2. Design the PKI path next. Decide whether to use Microsoft Cloud PKI, SCEP/NDES, PKCS, or imported certificates, and document trust chains, subject naming, renewal windows, and revocation expectations.
  3. Standardize Wi-Fi where possible on enterprise authentication such as EAP-TLS instead of shared secrets, and confirm that the enrollment mode supports the certificate and Wi-Fi settings you intend to use.
  4. Choose VPN patterns intentionally: per-app VPN for approved work apps, Always On where the business truly requires it, and split-tunnel versus full-tunnel decisions based on risk and dependency mapping.
  5. Build compliance and Conditional Access around the design so only the right devices can receive or use sensitive network access settings.
  6. Pilot end to end: enroll device, receive certificate, join Wi-Fi, establish VPN, access resource, rotate certificate, and validate what happens when the device becomes noncompliant.

Reference​