*This is post 1 of 6 in Avertium's "The Trust Problem in Enterprise Security" blog series
By Sarah Clarke, Consultant - QSA and AI Architect
Adobe pushed an emergency patch for CVE-2026-34621 in April. It's an Acrobat Reader zero-day that had been exploited in the wild since November 2025. CISA added it to KEV and gave federal agencies two weeks to patch. Earlier this year Fortinet shipped fixes for an authentication bypass in FortiOS, a command injection in FortiSIEM, a cloud SSO bypass, and a SAML flaw. Each gave an unauthenticated attacker administrative access to something that shouldn't have offered it.
After enough advisories, if you’re paying attention, you stop seeing them as discrete events. You see a pattern. From the assessor’s side of the table, it's a scope problem.
Most enterprise stacks rest on a small group of vendors trusted to act as the foundation - your firewall, your identity provider, your endpoint agent, and now the AI agents you've started letting near your data. When that trust holds, the architecture works. When it doesn't, the foundation crumbles.
*Trusted* is a load-bearing word nobody defines. *In scope* is the compliance version, and on a PCI engagement, it's the word the entire assessment hinges on.
A firewall is trusted to decide what gets through. An identity provider says who someone is. Endpoint agents run at kernel level on every device that touches your data. Your AI copilot reads your tickets, your logs, your code - and now acts on your behalf. Acrobat is trusted because everyone opens PDFs.
None of this is trust in any cryptographic sense. It's operational trust - the kind few design around because there’s limited time, budget, or political capital to assume the foundation can break. And every one of these components changes the scope of someone's compliance program, usually without that being documented.
Most security programs run that bet. It works most of the time. This series is about when it doesn't.
Three shifts have made the bet riskier in the last eighteen months.
Exploitation got faster: CVE-2024-55591 was a zero-day before Fortinet knew about it. The Adobe Acrobat CVE patched in April had been live for roughly five months before disclosure. Patching can't be the primary control for a class of vulnerabilities already in use before you knew they existed.
Vendor concentration deepened: Stacks consolidated for good operational reasons. The trade-off is blast radius. When one vendor owns your firewall, your VPN, and your SIEM, a single authentication bypass becomes an architecture-wide event, and from an assessor's perspective, a scope-wide one.
AI has come on fast and strong: AI agents are getting the same operational trust we give firewalls and EDR. They sit inside the boundary, hold privileged access to data and identity, and act on behalf of users. Every new system connection expands scope. The industry doesn't yet have a mature model for what happens when one is compromised, or what an assessor should be asking about it.
Conversations about vendor vulnerabilities slide into fatalism easily. *Patch faster* is a real answer, but it's not the one I'm asking about when I sit across the table from a client.
Patching closes the disclosed window – the one that is known. It does nothing about the window before disclosure, where more of the damage is happening in today’s threat landscape. The architecture that allowed the exploitation path is unchanged. And the next critical CVE from the same vendor is already in someone's bug queue.
What most programs are missing is something else; a written, defendable position on what each trusted component is allowed to break without taking the whole architecture down, and on what's in scope when it does.
That's a different question than “are we patched?”. It's the one this series will spend several posts unpacking, from both sides of the table.
Four more posts after this one:
”The Identity Provider as Attack Surface” covers what changes when the identity provider (IdP) becomes the breach and why your IdP is in PCI scope whether you've written it down or not.
”AI Agents Inside the Perimeter” discusses how agents pull themselves into compliance scope the moment they touch regulated data and what an assessor will actually ask about, and what most AI deployments can't answer yet.
”Vendor Concentration as a Board-Level Risk Metric” talks about how to put a number on architectural dependency that doesn't show up in any framework. This includes how concentration changes what an assessor sees when they walk into your environment.
”Where the Frameworks Fall Short” addresses what PCI DSS 4.0, HIPAA, and SOC 2 quietly assume about vendor trust and what compensating controls assessors should be asking for and aren't yet.
Then, the closing post pulls the thread into an operating posture I call structured skepticism, running a high-trust architecture while refusing to grant trust by default.
Here’s something concrete you can do before the next standup with your PCI provider. No project, no budget, no vendor call.
1. List every product in your environment that holds privileged trust:For most organizations, that third column is mostly blank. That blank is the trust architecture problem in one artifact. The rest of this series is what to do about it — as an architect, as a compliance lead, and as the person who must defend the answer to an assessor.
Stay tuned for our second post in the series, ”The Identity Provider as Attack Surface,” which will publish on June 10, 2026 at 10:00 am EST.