Trust in computer security is an essential concept that underpins every aspect of system design and operation. It is one of the easiest concepts to conceptualize and reason about, but also one that is broadly difficult to get right, particularly across boundaries. To address these challenges, modern security practice dictates that systems should eliminate trust from their design.
However, even with the prevalence of Zero Trust as an approach, we continue to see solutions that inherently require exceptional trust from customers. This is particularly evident with Software-as-a-Service where vendors have taken upon themselves the responsibility to operate software on behalf of their customers, including most, if not all, security considerations. The supposition is that if the security function is concentrated with the vendor, all customers who share in the use of that managed service will benefit.
Uptake of the centralized SaaS model is predicated on trusting that the vendor we provide our data to will protect it to the same or higher level than we would, and that they are in a better position to deliver on those goals than we are. Apart from reviewing summaries of scoped security audits or questionnaires, SaaS customers typically have no ability to reduce trust by verifying security posture directly.
Patrick Opet, the Chief Information Security Officer at J.P. Morgan Chase, recently commented on security concerns associated with the SaaS delivery model in an open letter to suppliers. He notes that time-tested methods for securing systems and the benefits of distributed software deployment have given way to third-party, centrally managed services. While acknowledging rapid innovation and certain efficiencies to centralized SaaS, he shines a light on the flawed incentive structure this model presents. Shielded from direct scrutiny from customers and responding to competitive pressure, Patrick notes that vendors regularly make tradeoffs in product and engineering decisions that prioritize market share and speed over security.
Pay No Attention to the System Behind the Curtain
These concerns are not hyperbolic. In late August 2025, a maker of a sales-oriented AI chat service experienced a breach wherein authentication tokens to various SaaS platforms were obtained by attackers. These credentials permitted the AI chat service to read and write data in CRM and email systems on behalf of customers, and in the hands of attackers, permitted the same degree of access to some of the most sensitive data and systems in any business’s inventory. Crucially, the nature of centralized SaaS means that the protection of these credentials was the responsibility of the vendor, leaving customers with the unenviable choice of trusting the vendor with the keys to their kingdoms, or not using the service. In this instance, the vendor had all the right certifications and presented themselves as worthy of customer trust. But by taking it upon themselves to manage service integration tokens and coming up short to the task, their customer base is left scrambling to determine the scope of their losses, and platform service providers are tasked with defensive clean up efforts to stem the tide.
Among the areas of a business's operations most at risk from excess trust in vendors is centralized SaaS for network access. Vendors in this area operate global access networks that are shared by their customers, effectively serving as multi-tenant corporate networks. These vendors describe their offerings as Zero Trust Network Access products, but ask that customers trust them with:
- all of their private network traffic;
- the encryption keys to that private traffic; and
- the capability of adding devices to private customer networks,
all in the pursuit of eliminating trust from the customer’s network.
Security research from August 2025 discovered critical authentication bypasses, cross-tenant user impersonation attacks, and privilege escalation exploits in centralized SaaS network access providers. These vulnerabilities are amplified by their universal and immediate impact on the private networks of all customers of these providers. At least one of the vendors in the research target group does not disclose vulnerabilities for “server-side” issues, which refers to the intermediate infrastructure the vendor operates on behalf of customers, and which handles authentication and traffic flows. As a result, not only are customers unable to directly control their security exposure using these products, they may also have no way of knowing about the existence of a vulnerability that impacts them, even if the vendor knows.
Architectural Regression
Patrick describes the shift of operational security controls to vendors, the concentration of customer data into a handful of provider systems, and the breakdown of trust boundaries among systems as an architectural regression. Speaking for the largest financial institution in the United States, he calls for the prioritization of the security of systems to at least at the same level of importance as the system’s main functions, security by design, and controls and visibility to allow customers to operate systems safely.
One Step Forward, Two Steps Back
There is an implicit recognition among SaaS vendors that their offerings have shortcomings, as evidenced by how they approach security-conscious customers. For many government customers and their contractors, the risks of cascading failure, the outsourcing of operations, the opacity of control existence and effectiveness, and marginal visibility into data flows and handling practices are unacceptable.
Nonetheless, government customers demand capabilities that new products provide, and so when a vendor’s product reaches a certain level of impact, the industry standard approach for addressing security concerns has been to introduce a GOV version of the product. The GOV mark, and its various synonyms, is meant to convey that this version of the SaaS lives up to the responsibilities and requirements federal government customers demand of their vendors.
These GOV instances are typically separated from commercial deployments, and make guarantees regarding data residency and protection. Also typical of the GOV pattern is that these versions tend to trail behind their commercial counterparts in terms of feature sets, often do not integrate with their commercial equivalents for core functions such as collaboration, and are priced significantly higher.
While the GOV pattern does present a more serious commitment to the security concerns that organizations such as the federal government will not compromise on, at best this approach only validates that the mainline offerings have serious shortcomings, and at worst operate as a placebo with pronounced shortcomings that hamstring customers.
Shifting Our Mindset: The Secure by Architecture Strategy
GOV style improvements to centralized SaaS security may be better than nothing, but the narrow focus and reach of these solutions leaves a yawning gap in the general security posture most businesses have reasonable access to. To eliminate the need for blind trust in vendors and to allow customers agency over their own security, we need a foundational change in the way software is architected and delivered to customers. We need a mindset shift toward the notion that these systems belong to the customers that use them – not in the sense of software copyright, but as a basic and first principle of operations. It is inherently challenging for SaaS vendors to treat something they create as belonging to another, but accepting this posture is essential for the creation of functionality that eliminates trust from systems – especially with regard to security. In essence, the facilities need to exist to enable customer agency over their data as if the customer themselves created the system, giving them total control.
Extending customers an ownership interest in the security aspects of managed systems that process their data is multifaceted, but includes at a minimum:
- data protection not only against third parties, but also from the vendor themselves;
- absolute controls over system operation; and
- rich visibility into data flows.
Protecting Data, Especially from Vendors
Too often, SaaS solutions are built to protect data only against unauthorized third-party access, when in fact any access other than customer access should be considered authorized, including by the vendor. Whether for analytics, support, or other internal uses, vendors regularly justify retaining the ability to access customer data. The technology exists to encrypt and anonymize data such that only customers may access their information. These technologies include, for example, customer-managed keys, confidential computing, and tokenization. However, achieving this level of protection requires vendors to truly accept that their access to customer data should be curtailed to the greatest extent possible, at the outset, and that this posture needs to be the easy, default state – not something that customers need to jump through hoops to attain.
Use Real Controls
Effecting this manner of data protection requires that security controls be architected on the premise that the system belongs to the customer, and that they should have maximal expression of how data should be accessed, by whom, from where, and under what conditions. Customers should have visibility and control over secrets management, rotation, views into usage patterns, authority over scopes, and revocation authority. These controls should consider the vendor to be an external party, requiring vendor access to be authorized and logged just as any use of the system would be.
Owner-level Visibility is Mandatory
Rich visibility into data flows includes detailed logging about which actors are accessing what data, complete with metadata such as time, manner, agent, source, and destination. These types of logs are the first touch point of any incident response, and should be readily available to customers of these systems, to the same degree as the vendor, tempered only by the need for tenant isolation, customer privacy, and data protection.
Universal Entitlement
These elements of SaaS security must receive the same ease of usability treatment that the mainline feature set of the application receives, and, crucially, these functions must be made available for all consumers of the application, not locked behind restrictive product tiering.
Exercise Agency with Bowtie
Agency over customer security is not optional. Network access is among the most sensitive systems any business operates, and Bowtie is built from the ground up to empower customers to build secure systems without needing to blindly trust Bowtie. Leveraging our database from the future, Bowtie keeps customer data entirely in customer hands. Customer traffic never crosses over into infrastructure operated by Bowtie because Bowtie does not operate infrastructure on behalf of our customers. This architecture means there is no possibility of Bowtie ever accessing any private customer traffic.
In network security, software products must be deployed on clients and alongside destination resources. While other vendors place themselves in the middle of connections between clients and customer resources, Bowtie’s control plane forms a mesh across each instance of the software inside customer environments, eliminating the need for Bowtie to sit in the middle, and thereby removing the need to trust Bowtie as an operational part of customer networks.
Also as a consequence of our control plane mesh, customers have total visibility into every aspect of data flows in and out of their Bowtie deployment. This is made possible both at their own network gateways as well as from detailed logs and telemetry that Bowtie controllers emit to any system customers choose for aggregating security event information.
We call this approach Decentralized SaaS. We have designed in the same ease of use and burden offload that is the hallmark of centralized SaaS, while affording customers complete control over their system and agency to ensure secure outcomes. Patrick Opet laments the degradation of security capabilities in modern SaaS, but Bowtie shows that you can have the best of both worlds.
