<![CDATA[The Cost of Ambiguity]]>https://thecostofambiguity.comhttps://thecostofambiguity.com/img/substack.pngThe Cost of Ambiguityhttps://thecostofambiguity.comSubstackWed, 21 Oct 2026 11:46:08 GMT<![CDATA[The Valuation Spread]]>https://thecostofambiguity.com/p/the-valuation-spreadhttps://thecostofambiguity.com/p/the-valuation-spreadTue, 20 Oct 2026 17:32:00 GMTMost security problems don’t start in code. They start in a meeting where nobody wrote down who was supposed to do what.

Engineering wants to hit its sprint dates without waiting days for a deployment approval. Sales and customer support want open permissions so they can close tickets, and they will tell you, in so many words, that security is getting in the way of revenue. Caught between the two, most organizations take the easiest path available: standing administrative rights, one service token shared across a dozen applications, and permission boundaries left wide open “for now.” To a sales lead or an engineering manager, this looks like agility. To a CFO, a board risk committee, or the underwriter on the other side of a deal, it is a liability that nobody has priced yet.

I call this access debt. Like most technical debt, it is rarely the product of bad code or bad people; it is what builds up when a business never decides, in writing, what a given role is actually allowed to do. Every standing privilege is a small decision someone made on their own because the real decision was never made for them.

This matters most for growth-stage companies on their way to a liquidity event. Whether that event is an IPO or an acquisition, the company’s access practices will eventually be read by people whose job is to price risk: underwriters, an acquirer’s diligence team, and, once the company lists, public investors reading its annual report.

Why This Belongs on the Balance Sheet

The numbers are not small. Compromised credentials were the initial access vector in 22% of the breaches Verizon reviewed for its 2025 Data Breach Investigations Report, more than any other single point of entry. IBM’s 2025 Cost of a Data Breach report puts the average cost of a breach that began with stolen credentials at $4.67 million, and those breaches took an average of 246 days to identify and contain. A leaked token that works in one place is an incident. A leaked token that works everywhere is a company-wide event.

This exposure doesn’t stay in the technical appendix anymore, either. Under the SEC’s 2023 cybersecurity rules, a public company must describe in its annual 10-K (Regulation S-K, Item 106) its “processes, if any, for assessing, identifying, and managing material risks from cybersecurity threats,” along with how the board oversees that risk, and a material incident has to be disclosed on Form 8-K under Item 1.05. Note the words “if any.” The SEC is asking about process, not tooling, and the rule allows for the possibility that a company doesn’t have much of one to describe.

For a pre-IPO company, the timing matters. When the rule was proposed, the SEC’s own Investor Advisory Committee recommended extending Item 106 to IPO registration statements, stating that “pre-IPO companies may face heightened [cybersecurity] risks.” The SEC declined, citing its efforts to reduce the burden of the rule. It did, however, repeat its earlier guidance that “companies should consider the materiality of cybersecurity risks and incidents when preparing the disclosure that is required in registration statements,” which in practice means the risk factors in the S-1. Then, in its first annual report as a public company, the business has to describe its processes in full. A company that spent its growth years without defined roles or access processes will have to put that in writing, in public.

Most growth-stage companies end up in one of two places, a public listing or an acquisition, and both run through diligence. The best published evidence of how diligence prices security findings comes from acquisitions. In a 2025 master’s thesis at Aalto University School of Business, Tua Halen interviewed thirteen practitioners with experience in cybersecurity due diligence on EU transactions and asked each of them to estimate how much a target’s cybersecurity posture moves its valuation. Almost half put it between 1% and 5% of the deal. One interviewee said that an impact of around 5% would already mean the “whole company is full of holes – like cheese,” and another said the models they use for Monte Carlo analysis assume 5% to 8%. For data-driven or digitally dependent companies with serious weaknesses, five of the interviewees put the potential impact at 10% to 20%, and eight said cybersecurity can stop a deal outright. As one of them put it, “if the deal is 300 M€, then that’s 300 M€ impact.” It’s a small, qualitative sample, and it’s European, but it matches the rule of thumb I have heard in practice.

The same study found something I think matters more to this audience than any percentage. Cybersecurity, it concludes, “shapes a company’s valuation only to the extent that organisations are able to translate technical findings into financially meaningful information.” Valuation teams often don’t have the technical vocabulary to read a detailed security report, and security teams aren’t used to framing risk in financial terms. Most of the time, then, the finding doesn’t disappear; it just ends up somewhere other than the price.

The best-known public example is Yahoo. After Yahoo disclosed two massive data breaches, Verizon cut its purchase price by $350 million, from roughly $4.83 billion to $4.48 billion (about 7.25%), and the amended agreement left Yahoo responsible for half of any breach-related liabilities still unresolved at closing and all of the ones already decided. That 7.25% sits above the 1% to 5% most of Halen’s interviewees considered typical, which is about what you would expect for two undisclosed breaches of that scale. Yahoo’s breaches weren’t a story about shared service tokens. The lesson is what happens to a price once a buyer can attach a number to a security failure.

Put two growth-stage companies side by side, with similar revenue, similar growth, and similar products. One can show who has access to what, why, and for how long. The other can’t. The difference in what a buyer or the market will pay for each is what I call the valuation spread. Halen’s interviewees put it at a few percent in an ordinary deal; Yahoo shows what it looks like when the deal isn’t ordinary.

Access architecture doesn’t have to be a tax on sales or a bottleneck for engineers. Built with automated, ephemeral permissions scoped to the task at hand (the least-privilege principle in NIST SP 800-53, control AC-6), it protects customer momentum and narrows that spread at the same time.

The Anatomy of Access Debt

Access debt doesn’t build up because teams are careless. It builds up because they are rewarded for moving fast and the process they would need is either missing or was never defined. Where nobody has decided who owns a decision, the team under the most pressure makes it, and makes it in favor of speed. When governance does exist but means a manual review or a multi-day approval queue, good teams will treat the control as the defect and find a way around it. The workarounds usually fall into three groups. This isn’t a comprehensive list, but most growth-stage tech companies will recognize at least one of them, and many will recognize all three.

1. Non-Human Identity Sprawl

Service-to-service communication is often designed for speed rather than attribution. Nobody owns service identities, and there is no standard for how one service should authenticate to another, so the fastest option wins. A single static API token gets issued once and shared across several microservices because it was the quickest way to get them talking to each other. Once that happens, the audit trail is gone. There is no way to tell which service made which call, and a compromise of the least important service hands an attacker the same access as the most important one.

2. Engineering and Debugging Shortcuts

To meet sprint commitments and troubleshoot live configurations, engineers skip the test environments. Some are given permanent, highest-privilege access to log directly into customer production tenants so they can “see what the customer sees,” in place of a sandbox, an anonymized test tenant, or timeboxed, audited Just-In-Time (JIT) access. Others leave static credentials open between staging and production so they can debug a live issue without going through the proper authentication path. Both happen because nobody defined how engineers should get realistic test data or a working test tenant, so production became the test environment.

3. Commercial and Support Accommodations

Revenue and customer-facing teams want access now. Customer Success is handed global admin or database access, with no expiration, so they can resolve tickets without waiting on an engineering escalation. Support teams in different regions share communal accounts to avoid buying individual seats or setting up proper identity boundaries. Both come from the same gap: there is no defined escalation path, and no agreed scope for what a support role should be able to touch.

The Compounding Blast Radius

With shared tokens, the decision belonged to the platform team. With production logins, it belonged to engineering. With support grants, it belonged to Customer Success. Each concession looks minor on its own, and each was made by a team trying to do its job. Nobody, however, owns the sum of them, and together they take apart the internal boundaries the company believes it has.

When a credential is eventually leaked or mishandled, those open paths turn a small incident into a large one in two ways. First, if several microservices share one token, the incident response team can’t isolate which service was compromised, and containment stalls because revoking the token breaks every service that depends on it. Second, if engineers use unrestricted production impersonation in place of scoped, timeboxed access, an attacker holding those credentials inherits access to every customer tenant at once. What should have been one contained ticket becomes a multi-million-dollar containment effort.

How Auditors Turn Shortcuts into Findings

Diligence teams and security auditors don’t spend much time on policy documents. They read transaction logs, configuration files, and permission boundaries, and then they ask the target to explain what they found. One of Halen’s interviewees described the conversation this way: “credentials to your system are available for 5€ on the internet, what do you think of that?” When informal workarounds meet that kind of scrutiny, they become findings.

The Shared Token

A shared service token is a dead end for anyone analyzing API access logs. Because several services use the same static credential, no identity is attached to the calls, and auditors treat unattributed service-to-service traffic as an unmonitored perimeter, which is to say a failure to maintain internal controls over data boundaries.

The Impersonation Session

Production impersonation fails for a different reason. Auditors look for proof that customer tenants are deterministically separated. Impersonation with no time limit shows that an internal user can reach customer data without explicit, time-limited authorization or a record of customer consent. What the product team considers fast debugging, the auditor writes up as a breach of multi-tenant confidentiality.

From Finding to Deal Sheet

In an acquisition, once those findings are written down, the buyer’s deal team translates them into legal and financial terms. Halen’s interviewees were consistent on this point: when a risk can’t be quantified reliably, deal teams don’t usually adjust the valuation directly. They use clauses, warranties, and earn-outs to absorb the uncertainty instead.

  • Remediation holdbacks. The engineering hours needed to rebuild service authentication and stand up proper test environments are estimated and deducted from the purchase price. One interviewee described adding a clause stating that technical verification would be completed after signing, and that “after we know the remediation costs, they will be deducted from the deal price.”

  • Seller indemnification. Liability for pre-close data exposure is pushed back onto the seller (”all incidents before a certain date are the liability of the seller,” in another interviewee’s words). It’s the same mechanism, at a smaller scale, that left Yahoo holding half of its unresolved breach liabilities.

  • Earn-outs and pre-close conditions. Part of the price is tied to fixing specific findings, or the buyer requires them to be fixed before closing and before connecting any systems.

For the seller, this is the expensive version of the problem. A price adjustment is negotiated once. A clause that leaves you holding the liability stays with you after closing.

Ahead of an IPO, the same findings land in different places. They shape the risk factors in the S-1, and they become the substance of the processes the company will have to describe in its first 10-K. Whichever way the company exits, someone is going to ask for the paper.

You Cannot Automate an Ambiguous Role

Security failures are rarely the work of malicious employees; far more often, they are the result of how the system was set up. If requesting access means a multi-day queue, a tedious intake form, or waiting on a manual review, engineers and support leads will reasonably conclude that governance is the thing slowing them down. When a team has to choose between compliance and delivery, it will choose delivery every single time. The workarounds above are rational responses to that choice.

Where the Friction Comes From

Most of the sprawl appears where departmental incentives don’t line up. Security designs intake for auditability, while engineering designs workflows for throughput; when intake can’t keep pace with an automated deployment cadence, engineers build the persistent staging-to-production bridge. Support teams work against SLA clocks, and when an urgent customer issue requires an engineering escalation, a support manager will find a way to keep standing production credentials. Ask why, and the answer is usually some version of “just in case”...which is to say, nobody ever told them which case they would need it for.

The Real Bottleneck

Organizations that try to remove this friction with automated least privilege or JIT access often stall, and the reason is usually not technical. Modern identity engines and policy-as-code frameworks can grant, scope, and revoke access in milliseconds. The bottleneck is that the business hasn’t defined the role.

If task boundaries are loose, management can’t say which permissions a role needs to do its job. If roles aren’t maintained in a business system of record (a Single Source of Truth, or SSOT, such as Salesforce, an HRIS, or a central identity registry), there is no deterministic baseline for automation to build on.

You cannot write a deterministic policy for an ambiguous business role. When the business leaves task requirements vague, the security team is left with two bad options: grant broad standing access so nobody is blocked, or impose manual approval gates that slow everyone down. Neither one is really a security decision. Both are the cost of a business decision that was never made.

It’s also why the SEC’s “processes, if any” is a harder question than it looks. A company can’t describe a process for managing access risk if it never decided who should have access to what.

The Remedy: Ephemeral Access and Policy-as-Code

Once roles are defined and maintained in an SSOT, security architecture can move off static administrative rights entirely, and access provisioning stops being a ticket queue and becomes an automated workflow.

Just-In-Time Instead of Standing Access

Standing, static permissions sit at the lowest stage of CISA’s Zero Trust Maturity Model (v2.0), and NIST SP 800-207 describes the alternative. In practice, moving up the model looks like this:

  • Task-scoped provisioning. Access is granted for the duration of a specific, ticketed task, whether that’s an engineer who needs production or a Customer Success rep who needs admin rights in one tenant.

  • Expiring credentials. Credentials, database connections, and impersonation sessions are generated with an explicit time-to-live and revoked automatically when the task or window closes.

  • Zero standing privilege. With static credentials removed from service configurations and user directories, the persistent attack surface drops close to zero. An attacker who steals a token five minutes after the ticket closes is holding an expired artifact.

Policy as Code

The rules themselves are written as version-controlled code in a policy engine such as Open Policy Agent, so that a person under pressure isn’t the one making the call. If a Customer Success rep requests temporary access to a tenant to resolve an escalated tier-3 ticket in Salesforce, the engine checks that the ticket is open, confirms the rep’s role in the SSOT, issues a time-bound session token, and logs the session, all within milliseconds. Changes to policy go through the same CI/CD pipeline as application code, so they are visible, tested, and reviewed by peers like any other change.

Compliance as a Byproduct

The part that matters most to executives is that compliance evidence is produced as a side effect of daily work. Because each access event is tied to a business event and an expiring token, the system records the trail auditors ask for without anyone assembling it by hand:

FrameworkControlWhat ephemeral access providesNIST SP 800-53 Rev. 5AC-6 (Least Privilege)Least privilege enforced per task, on every interactionSOC 2 Type IICC6.1, CC6.3Access tied to an authorized business event, with automatic removalISO/IEC 27001:2022Annex A 5.15, 8.2Access control and privileged access rights logged end to end

Engineering teams stop losing weeks to evidence collection before each audit, and the board gets continuous proof of operational control in place of a scramble the month before a review. That distinction matters in diligence, too. Several of Halen’s interviewees said they treat certifications such as ISO 27001 and SOC 2 as a signal of maturity but not as proof; one said companies need to “show how they make the policy work and show proof.” An access log tied to real business events is exactly that proof.

What Changes, and for Whom

When security controls are built as static administrative hurdles, good teams route around them. When support is pressured to resolve tickets immediately and engineering is rewarded for shipping faster, permissions flatten and access debt grows. Asking those teams to slow down won’t fix it, and neither will asking engineers to put up with more friction. The fix is to remove the ambiguity that made standing permissions necessary in the first place.

If roles are defined by the business and kept in a system of record, and standing privileges are replaced with automated, ephemeral policy-as-code:

  • Engineers deploy without manual ticket bottlenecks or credentials embedded in their pipelines.

  • Customer Support resolves customer issues inside timeboxed boundaries that keep tenants isolated.

  • Executives and boards get a security and compliance posture they can demonstrate on any given day, not just the week before an audit.

Built this way, identity governance stops showing up as IT overhead and starts showing up where underwriters, acquirers, and eventually public investors actually look: in the price. Closing the valuation spread is what capital defensibility means in practice.

References & Frameworks Cited

Regulatory & Compliance Frameworks

Industry Benchmarks & Valuation Case Studies

]]>