I’ve seen a lot of zero trust setups, from off-the-shelf vendor tools to complex custom-built solutions. I’ve found that many of them share the same problems and below I’ve listed the most common 8 I see. These usually stem from the design phase so the earlier you catch them the better! Admittedly some are those gnarly enterprise security problems which require a culture change and effort shift, especially number 8 as increasing manual workloads is not usually the top priority.

  1. MDM Source Of Truth - MDMs are great tools but they are not well suited to be a source of truth for hardware in most companies. Ideally, you want a proper asset inventory (Jira, CMDB, ITSM, etc) before your MDMs assigns a user to a device. The reason being is that you want to identify legitimate corporate devices prior to them enrolling in your MDM. This way you can stop attackers from enrolling a secondary device for the user if you have a 1:1 matchup on which device a user should have. In addition to this rarely are all your devices in a single MDM, especially if you have lots of different form factors and operating systems. Apple is slowly releasing managed device attestation to help with this too.
  2. Certificate Deletion - So many setups I see simply delete their machine certificates with their MDM tools. This is fine from a cleanliness perspective but you really want to implement a certificate revocation or suspension function so that you can remove the trust for a certificate in the case of an incident. You can’t guarantee control over an endpoint in the case of a full compromise so you can’t guarantee you can delete it when it matters.
  3. Insecure Certificate Storage - A really common one that is made worse when paired with number two above. Where you store the certificates on devices absolutely matters. On macOS this is usually the device keychain with export disabled, on Windows, it’s the TPM. You should not have devices in your enterprise that don’t have the capability to store certificates securely. Ensure that you also keep to a relatively recent major operating system version as older versions can have lack of support or vulnerabilities which lessen the security of device stores.
  4. Long-Lived Sessions - Many implementations use sessions that are excessively large and don’t terminate these sessions when a device falls out of compliance. Try to reduce your sessions for high-risk applications and consider expiring sessions if a device falls out of compliance. This is especially critical for mobile where sessions tend to be longer, often in the realm of 90 days or longer.
  5. Single Detection Sources - The problem with client-based architectures is that the client controls all the requests. A user can nuke your MDM or EDR off a compromised device and while that device won’t check-in, you are likely no longer getting logs from it. A good recommendation to add to your detections is to use your MDM to detect suspicious commands affecting your EDR and vice versa. Using a double detection method you can get fairly high-fidelity alerts in the case of insider threat or compromise. It isn’t perfect, but it’s certainly better than a single point of failure.
  6. Complex Exception Groups - Having an exception process and escalation path is absolutely a good thing. You should be prepared for the unexpected and should be able to poke holes if needed. The main problem is having long-lived exceptions for minor use cases and building complex group structures to implement them. Zero Trust should be simple. As much as possible you want to timebox exceptions, have a signed escalation path and have valid use cases documented so exceptions don’t creep up over time.
  7. Service Accounts - Zero trust is easier to implement on the human identity side, often problems arise when service accounts get added into the mix. API and Robotic Process Automation (RPA) tools can cause issues with some zero trust implementations. This is especially prevalent in cases where RPA tools like UIPath need to impersonate a user in order to perform UI actions. Use traditional defense in depth techniques here, ensure least privilege, store the credentials securely and ideally enable dynamic secrets.
  8. Self-Service User Verification - If an attacker does manage to compromise an account or a workstation the first thing they will want to do is maintain persistence. One of the ways they can do this is by adding their own 2FA or device to the compromised account. Validation is key when it comes to these manual user interactions. People will lose their Yubikeys and need 2FA resets. Even video these days isn’t 100% valid with some deepfake technology so this is harder to do in a fully remote world. Try to strongly validate users, either via requiring them to auth to a service with strong 2FA and ideally doing such on a video call or in person.