Cutting Through the Hype―The Realistic Flaws of a Zero Trust Security Model

If your organization develops its own software for internal consumption, and the applications are more than a few years old, you may have technical debt. Loosely defined, technical debt refers to solutions based on older or obsolete technology that would not be used to develop new solutions today. Applications written in Cobol are an extreme example of technical debt.

Today, redesigning, recoding, and redeploying applications to replace technical debt can be costly and potentially disruptive. There needs to be a serious business need to undertake these types of initiatives. Adding security parameters to existing applications to make them zero trust-aware is not always feasible. Odds are your existing applications have no facilities today to accommodate a zero trust model.

Therefore, depending on how reliant you are on custom applications, this will dictate whether or not you can adopt zero trust to those processes, and potentially determine the effort and cost required. This is especially true in instances when applications are not microperimeter compatible, or lack Application Programming Interfaces (API) to support the required automation for a zero trust implementation.

Read more.