I’ve been thinking about Conway’s Law, the idea that organizations “ship their org chart.” The seams are most visible in big tech. Google, for example, once offered nearly a dozen messaging apps instead of a single excellent one, with each team fighting for resources. The same pattern appears everywhere: companies struggle to solve problems that cross organizational boundaries because bureaucracy and incentives keep everyone guarding their turf. The issue is not the technology; it is human nature.
I caught up with an old friend recently. We met at nineteen while working for one of the first cybersecurity companies, and now, in our fifties, we both advise organizations of every size on innovation and problem-solving. We agreed that defining the technical fix is the easy part; the hard part is steering it through people and politics. When change shows up, most organizations behave like an immune system attacking a foreign antibody. As Laurence J. Peter wrote in 1969, “Bureaucracy defends the status quo long past the time when the quo has lost its status.”
Naturally, the conversation drifted to AI and how it will, or will not, transform the companies we work with. I explored this in two recent posts [1,2]. We have seen the same thing: not everyone is good at using AI. The CSOs and CTOs we speak with struggle to help their teams use the technology well, while a handful of outliers become dramatically more productive. The gap is not access or budget; it is skill. Today’s AI rewards people who can break problems down, spot patterns, and think in systems. Treat the model like a coworker and you gain leverage; treat it like a tool and you barely notice a difference.
That leverage is even clearer for solo founders. A single entrepreneur can now stretch farther without venture money and sometimes never need it. With AI acting as marketer, product manager, developer, and support rep, one person can build and run products that once demanded whole teams. This loops back to Conway’s Law: when you are the entire org chart, the product stays coherent because there are no turf battles. Once layers of management appear, the seams show, and people ship their structure. Peter’s Principle follows, people rise to their level of incompetence, and the bureaucracy that emerges defends that status.
Yet while AI empowers outliers and small players, it might also entrench new kinds of monopolies. Big tech, with vast data and compute resources, could still dominate by outscaling everyone else, even if their org charts are messy. The question becomes whether organizational dysfunction will outweigh resource advantages, or whether sheer scale still wins despite structural problems.
The traditional buffers that let incumbents slumber (high engineering costs, feature arms races, and heavy compliance overhead) are eroding. Payroll keeps rising and headcount is the biggest line item, while the newest startups need fewer people every quarter. I expect a new wave of private-equity-style moves: smaller players snapped up, broken into leaner parts, and retooled around AI so they no longer rely on large teams.
Social media voices such as Codie Sanchez highlight the largest generational transfer of wealth in history. Many family-owned firms will soon be sold because their heirs have no interest in running them. These so-called boring businesses may look ripe for optimization, because most still rely on human capital to keep the lights on. Just above that tier we see larger enterprises weighed down by armies of people who perform repetitive tasks. A modern consulting firm armed with AI could walk into any of these firms and automate vast swaths of monotonous work that keeps those businesses running. Incumbents will struggle to move that fast, trapped by the very structures we have been discussing. A private-equity buyer, on the other hand, can apply the playbook with no sentimental ties and few political constraints.
ATMs let banks cut tellers and close branches. Customers later missed human service, so smaller neighborhood offices came back. AI will force every sector to strike its own balance between efficiency and relationship.
They say history doesn’t rhyme but it repeats, if so incumbents who dismiss AI as hype may follow Blockbuster into the museum of missed opportunities. In Wall Street (1987), Michael Douglas plays Gordon Gekko, a corporate raider who uses leveraged buyouts to seize firms like Blue Star Airlines, an aircraft maintenance and charter company. Gekko’s playbook, acquire, strip assets, slash jobs, was ruthless but effective, exploiting inefficiencies in bloated structures. Today, AI plays a similar role, not through buyouts but by enabling leaner, faster competitors to gut inefficiencies. Solo founders and AI-driven startups can now outpace large teams, while private-equity buyers use AI to retool acquired firms, automating repetitive tasks and shrinking headcounts. Just as Gekko hollowed out firms in any industry, AI’s relentless optimization threatens any business clinging to outdated, bureaucratic org charts.
Across news, television, music, and film, incumbents once clung to their near-monopoly positions and assumed they had time to adapt. Their unwillingness to face how the world was changing, and their instinct to defend the status quo, led to the same result: they failed to evolve and disappeared when the market moved on.
TheAsk? incumbents, you need to automate before raiders do it for you.
When we discuss the WebPKI, we naturally focus on Certificate Authorities (CAs), browser root programs, and the standards established by the CA/Browser Forum. Yet for these standards to carry real weight, they must be translated into formal, auditable compliance regimes. This is where assurance frameworks enter the picture, typically building upon the foundational work of the CA/Browser Forum.
The WebTrust framework, overseen by professional accounting bodies, is only one way to translate CA/Browser Forum requirements into auditable criteria. In Europe, a parallel scheme relies on the European Telecommunications Standards Institute (ETSI) for the technical rules, with audits carried out by each country’s ISO/IEC 17065-accredited Conformity Assessment Bodies. Both frameworks follow the same pattern: they take the CA/Browser Forum standards and repackage them into structured compliance audit programs.
Understanding the power dynamics here is crucial. While these audits scrutinize CAs, they exercise no direct control over browser root programs. The root programs at Google, Apple, Microsoft, and Mozilla remain the ultimate arbiters. They maintain their own policies, standards, and processes that extend beyond what these audit regimes cover. No one compels the browsers to require WebTrust or ETSI audits; they volunteer because obtaining clean reports from auditors who have seen things in person helps them understand if the CA is competent and living up to their promises.
How WebTrust Actually Works
With this context established, let’s examine the WebTrust model prevalent across North America and other international jurisdictions. In North America, administration operates as a partnership between the AICPA (for the U.S.) andCPA Canada. For most other countries, CPA Canada directly manages international enrollment, collaborating with local accounting bodies like the HKICPA for professional oversight.
These organizations function through a defined sequence of procedural steps: First, they participate in the CA/Browser Forum to provide auditability perspectives. Second, they fork the core technical requirements and rebundle them as the WebTrust Principles and Criteria. Third, they license accounting firms to conduct audits based on these principles and criteria. Fourth, they oversee licensed practitioners through inspection and disciplinary processes.
The audit process follows a mechanical flow. CA management produces an Assertion Letter claiming compliance. The auditor then tests that assertion and produces an Attestation Report, a key data point for browser root programs. Upon successful completion, the CA can display the WebTrust seal.
This process creates a critical misconception about what the WebTrust seal actually signifies. Some marketing approaches position successful audits as a “gold seal” of approval, suggesting they represent the pinnacle of security and best practices. They do not. A clean WebTrust report simply confirms that a CA has met the bare minimum requirements for WebPKI participation, it represents the floor, not the ceiling. The danger emerges when CAs treat this floor as their target; these are often the same CAs responsible for significant mis-issuances and ultimate distrust by browser root programs.
Where Incentives Break Down
Does this system guarantee consistent, high-quality CA operations? The reality is that the system’s incentives and structure actively work against that goal. This isn’t a matter of malicious auditors; we’re dealing with human nature interacting with a flawed system, compounded by a critical gap between general audit principles and deep technical expertise.
Security professionals approach assessments expecting auditors to actively seek problems. That incentive doesn’t exist here. CPA audits are fundamentally designed for financial compliance verification, ensuring documented procedures match stated policies. Security assessments, by contrast, actively hunt for vulnerabilities and weaknesses. These represent entirely different audit philosophies: one seeks to confirm documented compliance, the other seeks to discover hidden risks.
This philosophical gap becomes critical when deep technical expertise meets general accounting principles. Even with impeccably ethical and principled auditors, you can’t catch what you don’t understand. A financial auditor trained to verify that procedures are documented and followed may completely miss that a technically sound procedure creates serious security vulnerabilities.
This creates a two-layer problem. First, subtle but critical ambiguities or absent content in a CA’s Certification Practice Statement (CPS) and practices might not register as problems to non-specialists. Second, even when auditors do spot vague language, commercial pressures create an impossible dilemma: push the customer toward greater specificity (risking the engagement and future revenue), or let it slide due to the absence of explicit requirements.
This dynamic creates a classic moral hazard, an issue similar to the one we explored in our recent post, Auditors are paid by the very entities they’re supposed to scrutinize critically, creating incentives to overlook issues in order to maintain business relationships. Meanwhile, the consequences of missed problems, security failures, compromised trust, and operational disruptions fall on the broader WebPKI ecosystem and billions of relying parties who had no voice in the audit process. This dynamic drives the inconsistencies we observe today and reflects a broader moral hazard problem plaguing the entire WebPKI ecosystem, where those making critical security decisions rarely bear the full consequences of poor choices.
This reality presents a prime opportunity for disruption through intelligent automation. The core problem lies in expertise “illiquidity”, deep compliance knowledge remains locked in specialists’ minds, trapped in manual processes, and is prohibitively expensive to scale.
Current compliance automation has only created “automation asymmetry,” empowering auditees to generate voluminous, polished artifacts that overwhelm manual auditors. This transforms audits from operational fact-finding into reviews of well-presented fiction.
The solution requires creating true “skill liquidity” through AI: not just another LLM, but an intelligent compliance platform embedding structured knowledge from seasoned experts. This system would feature an ontology of controls, evidence requirements, and policy interdependencies, capable of performing the brutally time-consuming rote work that consumes up to 30% of manual audits: policy mapping, change log scrutiny, with superior speed and consistency.
When auditors and program administrators gain access to this capability, the incentive model fundamentally transforms. AI can objectively flag ambiguities and baseline deviations that humans might feel pressured to overlook or lack the skill to notice, directly addressing the moral hazard inherent in the current system. When compliance findings become objective data points generated by intelligent systems rather than subjective judgments influenced by commercial relationships, they become much harder to ignore or rationalize away.
This transformation liquefies rote work, liberating human experts to focus on what truly matters: making high-stakes judgment calls, investigating system-flagged anomalies, and assessing control effectiveness rather than mere documented existence. This elevation transforms auditors from box-checkers into genuine strategic advisors, addressing the system’s core ethical challenges.
This new transparency and accountability shifts the entire dynamic. Audited entities can evolve from reactive fire drills to proactive, continuous self-assurance. Auditors, with amplified expertise and judgment focused on true anomalies rather than ambiguous documentation, can deliver exponentially greater value.
Moving Past the Performance
This brings us back to the fundamental issue: the biggest problem in communication is the illusion that it has occurred. Today’s use of the word “audit” creates a dangerous illusion of deep security assessment.
By leveraging AI to create skill liquidity, we can finally move past this illusion by automating the more mundane audit elements giving space where the assumed security and correctness assessments also happen. We can forge a future where compliance transcends audit performance theater, becoming instead a foundation of verifiable, continuous operational integrity, built on truly accessible expertise rather than scarce, locked-away knowledge.
The WebPKI ecosystem deserves better than the bare minimum. With the right tools and transformed incentives, we can finally deliver it.
TL;DR: Root programs, facing user loss, prioritize safety, while major CAs, with browsers, shape WebPKI rules. Most CAs, risking distrust or customers, seek leniency, shifting risks to billions of voiceless relying parties. Subscribers’ push for ease fuels CA resistance, demanding reform.
The recent Mozilla CA Program roundtable discussion draws attention to a fundamental flaw in how we govern the WebPKI, one that threatens the security of billions of internet users. It’s a classic case of moral hazard: those making critical security decisions face minimal personal or professional consequences for poor choices, while those most affected have virtually no say in how the system operates.
The Moral Hazard Matrix
The numbers reveal a dangerous imbalance in who controls WebPKI policy versus who bears the consequences. Browsers, as root programs, face direct accountability; if security fails, users abandon them. CAs on the other hand are incentivized to reduce customer effort and boost margins, externalize risks, leaving billions of relying parties to absorb the fallout:
A classic moral hazard structure, with a key distinction: browser vendors, as root programs, face direct consequences, lose security, lose users, aligning incentives with safety. CAs, while risking distrust or customer loss, often externalize greater risks to relying parties, leaving them to face the fallout betting that they wont be held accountable for these decisions.
Mapping the Accountability Breakdown
The roundtable revealed a systematic divide in how stakeholders approach CPS compliance issues. CAs, driven by incentives to minimize customer effort for easy sales and reduce operational costs for higher margins, consistently seek to weaken accountability, while root programs and the security community demand reliable commitments:
Position
Supported By
Core Argument
What It Really Reveals
“Revocation too harsh for minor CPS errors”
CA Owners
Policy mismatches shouldn’t trigger mass revocation
Want consequences-free policy violations
“Strict enforcement discourages transparency”
CA Owners
Fear of accountability leads to vague CPSs
Treating governance documents as optional “documentation”
“SLA-backed remedies for enhanced controls”
CA Owners
Credits instead of revocation for optional practices
Attempt to privatize trust governance
“Split CPS into binding/non-binding sections”
CA Owners
Reduce revocation triggers through document structure
Avoid accountability while claiming transparency
“Human error is inevitable”
CA Owners
Manual processes will always have mistakes
Excuse for not investing in automation
“Retroactive CPS fixes should be allowed”
CA Owners
Patch documents after problems surface
Gut the very purpose of binding commitments
“CPS must be enforceable promises”
Root Programs, Security Community
Documents should reflect actual CA behavior
Public trust requires verifiability
“Automation makes compliance violations preventable”
Technical Community
65+% ACME adoption proves feasibility
Engineering solutions exist today
The pattern is unmistakable: CAs consistently seek reduced accountability, while those bearing security consequences demand reliable commitments. The Microsoft incident perfectly illustrates this, rather than addressing the absence of systems that would automatically catch discrepancies before millions of certificates were issued incorrectly, industry discussion focused on making violations easier to excuse retroactively.
The Fundamental Mischaracterization
Much of the roundtable suffered from a critical misconception: the CPS is “documentation” rather than what it is, the foundational governance document that defines how a CA operates.
A CPS looks like a contract because it is a contract, a contract with the world. It’s the binding agreement that governs CA operations, builds trust by showing relying parties how the CA actually works, guides subscribers through certification requirements, and enables oversight by giving auditors a baseline against real-world issuance. When we minimize it as “documentation,” we’re arguing that CAs should violate their core operational commitments with minimal consequences.
CPS documents are the public guarantee that a CA knows what it’s doing and will stand behind it, in advance, in writing, in full view of the world. The moment we treat them as optional “documentation” subject to retroactive fixes, we’ve abandoned any pretense that trustworthiness can be verified rather than simply taken on blind faith.
Strategic Choices Masquerading as Constraints
Much CA pushback treats organizational and engineering design decisions as inevitable operational constraints. When CAs complain about “compliance staff being distant from engineering” or “inevitable human errors in 100+ page documents,” they’re presenting strategic choices as unchangeable facts.
CAs choose to separate compliance from operations rather than integrate them. They choose to treat CPS creation as documentation rather than operational specification. They choose to bolt compliance on after the fact rather than build it into core systems. When you choose to join root programs to be trusted by billions of people, you choose those responsibilities.
The CAs that consistently avoid compliance problems made different choices from the beginning, they integrated policy into operations, invested in automation, and designed systems where compliance violations are structurally difficult. These aren’t companies with magical resources; they’re companies that prioritized operational integrity.
The Technology-Governance Gap
The “automation is too hard” argument collapses against actual WebPKI achievements:
Challenge
Current State
Feasibility Evidence
CA Resistance
Domain Validation
Fully automated via ACME
65+% of web certificates
✅ Widely adopted
Certificate Linting
Real-time validation at issuance
CT logs, zlint tooling
✅ Industry standard
Transparency Logging
All certificates publicly logged
Certificate Transparency
✅ Mandatory compliance
Renewal Management
Automated with ARI
Let’s Encrypt, others
✅ Proven at scale
CPS-to-Issuance Alignment
Manual, error-prone
Machine-readable policies possible
❌ “Too complex”
Policy Compliance Checking
After-the-fact incident reports
Automated validation possible
❌ “Inevitable human error”
The pattern is unmistakable: automation succeeds when mandated, fails when optional. With Certificate Transparency providing complete visibility, automated validation systems proven at scale, and AI poised to transform compliance verification across industries, operational CPSs represent evolution, not revolution.
The argument is that these “minor” incidents don’t represent smoke, as in where there is smoke there is fire, when we know through past distrust events it is always a pattern of mistakes often snowballing while the most mature CA programs only occasional have issues, and when they do they deal with them well.
Trust Is Not an Entitlement
The question “why would CAs voluntarily adopt expensive automation?” reveals a fundamental misunderstanding. CAs are not entitled to being trusted by the world.
Trust store inclusion is a privilege that comes with responsibilities. If a CA cannot or will not invest in operational practices necessary to serve billions of relying parties reliably, they should not hold that privilege.
The economic argument is backwards:
Current framing: “Automation is expensive, so CAs shouldn’t be required to implement it”
Correct framing: “If you can’t afford to operate, securely, accuratley and reliably, you can’t afford to be a public CA”
Consider the alternatives: public utilities must maintain infrastructure standards regardless of cost, financial institutions must invest in security regardless of expense, aviation companies must meet safety standards regardless of operational burden. The WebPKI serves more people than any of these industries, yet we’re supposed to accept that operational excellence is optional because it’s “expensive”?
CAs with consistent compliance problems impose costs on everyone else, subscribers face revocation disruption, relying parties face security risks, root programs waste resources on incident management. The “expensive automation” saves the ecosystem far more than it costs individual CAs.
When Accountability Actually Works
The example of Let’s Encrypt changing their CPS from “90 days” to “less than 100 days” after a compliance issue is often cited as evidence that strict enforcement creates problems. This completely misses the point.
The “system” found a real compliance issue, inadequate testing between policy and implementation. That’s exactly what publishing specific commitments accomplishes: making gaps visible so they can be fixed. The accountability mechanism worked perfectly, Let’s Encrypt learned they needed better testing to ensure policy-implementation alignment.
This incident also revealed that we need infrastructure like ACME Renewal Information (ARI) so the ecosystem can manage obligations without fire drills. The right response isn’t vaguer CPSs to hide discrepancies, but better testing and ecosystem coordination so you can reliably commit to 90 days and revocations when mistakes happen.
The Solution: Operational CPSs
Instead of weakening accountability, we need CPSs as the living center of CA operations, machine-readable on one side to directly govern issuance systems, human-readable on the other for auditors and relying parties. In the age of AI, tools like large language models and automated validation can make this dual-purpose CPS tractable, aligning policy with execution.
This means CPSs written by people who understand actual issuance flows, updated in lock-step with operational changes, tied directly to automated linting, maintained in public version control, and tested continuously to verify documentation matches reality.
Success criteria are straightforward:
Scope clarity: Which root certificates does this cover?
Profile fidelity: Could someone recreate certificates matching actual issuance?
Validation transparency: Can procedures be understood without insider knowledge?
Most CPSs fail these basic tests. The few that pass prove it’s entirely achievable when CAs prioritize operational integrity over administrative convenience.
Systemic Reform Requirements
Fixing moral hazard requires accountability mechanisms aligned with actual capabilities. Root programs typically operate with 1-2 people overseeing ~60 organizations issuing 450,000+ certificates per hour, structural challenges that automation must address.
Clearer requirements for CPS documents, automated evaluation tools, clear standards
Scalable infrastructure requiring scope clarity, profile fidelity, and validation transparency
Standards Bodies
Voluntary guidelines, weak enforcement
Mandatory automation requirements
Updated requirements to ensure adoption of automation that helps ensure commitments are met.
Audit System
Annual snapshots, limited scope
Continuous monitoring, real-time validation
Integration with operational systems
Root programs that tolerate retroactive CPS fixes inadvertently encourage corner-cutting on prevention systems. Given resource constraints, automated evaluation tools and clear standards become essential for consistent enforcement.
The Stakes Demand Action
Eight billion people depend on this system. We cannot allow fewer than 60 CA owning organizations to keep treating public commitments as optional paperwork instead of operational specifications.
When certificate failures occur, people lose life savings, have private communications exposed, lose jobs when business systems fail, or face physical danger when critical infrastructure is compromised. DigiNotar’s 2011 collapse showed how single CA failures can compromise national digital infrastructure. CAs make decisions that enable these risks; relying parties bear the consequences.
The choice is stark:
Continue excuse-making and accountability avoidance while billions absorb security consequences
Or demand that CAs and root programs invest in systems making trust verifiable
The WebPKI’s moral hazard problem won’t solve itself. Those with power to fix it have too little incentive to act; those who suffer consequences have too little voice to demand change.
The WebPKI stands at a turning point. Root programs, the guardians of web privacy, are under strain from the EU’s eIDAS 2.0 pushing questionable CAs, tech layoffs thinning their teams, and the U.S. DOJ’s plan to break up Chrome, a cornerstone of web security. With eight billion people depending on this system, weak CAs could fuel phishing scams, data breaches, or outages that upend lives, as DigiNotar’s 2011 downfall showed. That failure taught us trust must be earned through action. Automation, agility, and transparency can deliver a WebPKI where accountability is built-in. Let’s urge CAs, root programs, and the security community to adopt machine-readable CPSs by 2026, ensuring trust is ironclad. The time to act is now, together, we can secure the web for our children and our grandchildren.
Why the 2025 Amendments to EO 14144 Walked Back Progress on PQC, SBOMs, and Enforcement, Even as the Products to Support Them Have Become Real.
The June 2025 amendments to Executive Order 14144 read like a cybersecurity manifesto. They name adversaries (China, Russia, Iran, North Korea) with unprecedented directness and reference cutting-edge threats like quantum computing and AI-enabled attacks. The rhetoric is strong. The tone, urgent.
But beneath the geopolitical theater, something quieter and more troubling has happened. The Executive Order has systematically stripped out the enforcement mechanisms that made federal cybersecurity modernization possible. Mandates have become “guidance.” Deadlines have turned into discretion. Requirements have transformed into recommendations.
We’re witnessing a shift from actionable federal cybersecurity policy to a fragmented, voluntary approach, just as other nations double down on binding standards and enforcement.
The Enforcement Rollback
The most visible casualty was the software bill of materials (SBOM) mandate . The original EO 14144 required vendors to submit machine-readable attestations, with specific deadlines for updating federal procurement rules. These requirements have been entirely deleted.
This removal actually makes sense. Most SBOMs today are fundamentally broken: generated manually, and don’t actually match to deployed artifacts. Without robust validation infrastructure, SBOMs create more noise than signal. Use cases like vulnerability correlation break down when the underlying data is untrustworthy.
Once you have reproducible builds and verifiable provenance pipelines, SBOMs become implicit in the process. The government was both premature and naive in requiring SBOMs before the ecosystem could reliably generate them and do something with them. More fundamentally, they hooed that mandating documentation would somehow solve the underlying supply chain visibility problem – unfortunately thats not the case.
But SBOMs are a symptom of deeper issues: unreproducible builds, opaque dependency management, and post-hoc artifact tracking. Simply requiring vendors to produce better paperwork was never going to address these foundational challenges. The mandate confused the deliverable with the capability.
What’s more concerning is what else disappeared. Provisions mandating phishing-resistant multi-factor authentication, real-time interagency threat sharing, and specific timelines for aligning federal IT procurement with Zero Trust requirements all vanished. The detailed Border Gateway Protocol security language was replaced with generic “agency coordination” directives. The EO stripped away near-term pressure on vendors and agencies alike.
Yet even as these enforcement mechanisms were being removed, the amendments introduced something potentially transformative.
Rules as Code: Promise, Paradox, and Perfect Timing
The most exciting addition is buried in bureaucratic language. A pilot program for “machine-readable versions of policy and guidance” in cybersecurity appears almost as an afterthought. While the EO doesn’t name OSCAL explicitly, this is almost certainly referring to expanding the Open Security Controls Assessment Language use beyond its current FedRAMP usage into broader policy areas.
This could be transformative. Imagine cybersecurity policies that are automatically testable, compliance that’s continuously verifiable, and security controls that integrate directly with infrastructure-as-code. OSCAL has already proven this works in FedRAMP: structured security plans, automated assessment results, and machine-readable control catalogs. Expanding this approach could revolutionize how government manages cybersecurity risk.
But there’s something deliciously ironic about the timing. We’re finally standardizing JSON schemas for control matrices and policy frameworks just as AI becomes sophisticated enough to parse and understand unstructured policy documents directly. It’s almost comical. Decades of manual compliance work have driven us to create machine-readable standards, and now we have “magical AI” that could theoretically read the original messy documents.
Yet the structured approach remains the right direction. While AI can parse natural language policies, it introduces interpretation variations. Different models might understand the same requirement slightly differently. OSCAL’s structured format eliminates ambiguity. When a control is defined in JSON, there’s no room for misinterpretation about implementation requirements.
More importantly, having machine-readable controls means compliance tools, security scanners, and infrastructure-as-code pipelines can directly consume and act on requirements without any parsing layer. The automation becomes more reliable and faster than AI interpretation. Real-time compliance monitoring really only works with structured data. AI might tell you what a policy says, but OSCAL helps you build systems that automatically check if you’re meeting it continuously.
This pattern of promising technical advancement while retreating from enforcement continues in the amendments’ approach to cryptographic modernization.
The Post-Quantum Reality Check
Then there’s the post-quantum cryptography provisions. The EO requires CISA and NSA to publish lists of PQC-supporting products by December 2025, and mandates TLS 1.3 by January 2030.
The TLS 1.3 requirement appears to be carried over from the previous executive order, suggesting this wasn’t a deliberate policy decision but administrative continuity. The amendment specifically states that agencies must “support, as soon as practicable, but not later than January 2, 2030, Transport Layer Security protocol version 1.3 or a successor version.” More tellingly, the 2030 timeline likely reflects a sobering recognition of enforcement reality: federal agencies and contractors are struggling with basic infrastructure modernization, making even a five-year runway for TLS 1.3 adoption potentially optimistic.
This reveals the central tension in federal cybersecurity policy. The infrastructure is calcified. Legacy systems, interception-dependent security architectures, and procurement cycles that move at geological speed all contribute to the problem. A 2030 TLS 1.3 mandate isn’t visionary; it’s an acknowledgment that the federal government can’t move faster than its most outdated components.
But this enforcement realism makes the broader PQC timeline even more concerning. If we need five years to achieve TLS 1.3 adoption across federal systems, how long will the actual post-quantum migration take? By 2030, the question won’t be whether agencies support TLS 1.3, but whether they’ve successfully migrated key exchange, digital signatures, and PKI infrastructure to post-quantum algorithms. That’s a far more complex undertaking.
In essence, the EO treats PQC like a checklist item when it’s actually a teardown and rebuild of our cryptographic foundation. Historically, the federal government has led cryptographic transitions by creating market demand and demonstrating feasibility, not by setting distant mandates. When the government moved to AES or adopted Suite B algorithms, it drove adoption through procurement pressure and early implementation.
Meanwhile, allies like the UK and Germany are taking this traditional approach with PQC. The UK’s National Cyber Security Centre has published detailed migration timelines and will launch a pilot program to certify consultancy firms that provide PQC migration support to organizations. Germany’s Federal Office for Information Security has been leading in co-developing standards and demonstrating early government adoption. They’re creating market pull through demonstrated feasibility, not regulatory deadlines that may prove unenforceable.
Beyond cryptography, the EO does introduce some concrete requirements, though these represent a mixed bag of genuine progress and missed opportunities.
The EO also tasks NIST with updating key frameworks and calls for AI-specific vulnerability coordination. All valuable work. But notably absent: any requirement for agencies to adopt, implement, or report on these updated frameworks.
One genuinely new addition is the IoT Cyber Trust Mark requirement: by January 2027, federal agencies must require vendors of consumer IoT products to carry the labeling. This represents concrete procurement leverage, though it’s limited to a narrow product category.
These mixed signals, technical infrastructure development alongside enforcement retreat, reflect a broader pattern that undermines the federal government’s cybersecurity leadership.
As we’ve explored in previous discussions of AI’s impact on compliance, this shift toward automated policy interpretation and enforcement represents a broader transformation in how expertise flows through complex systems, but only when the underlying mandates exist to make that automation meaningful.
We’re building this sophisticated machine-readable infrastructure just as the enforcement mechanisms that would make it meaningful are being stripped away. It’s like having a perfectly engineered sports car but removing the requirement to actually drive anywhere.
The Infrastructure Is Ready. The Mandate Isn’t.
Federal cybersecurity policy shapes vendor behavior, influences state and local government standards, and signals U.S. priorities to international partners. Without centralized mandates, vendors receive mixed signals. Agencies implement inconsistently. Meanwhile, international partners advance with clearer timelines and stronger enforcement. The U.S. risks ceding leadership in areas where it built the foundational standards, just as adversaries accelerate their own capabilities.
The United States has built remarkable cybersecurity infrastructure. OSCAL for automated compliance, frameworks for secure software development, and draft PQC standards for cryptographic transition all represent genuine achievements. But the June 2025 amendments represent a retreat from the leadership needed to activate this infrastructure.
We have the tooling, standards, and momentum, but we’ve paused at the moment we needed to press forward. In the face of growing threats and global urgency, discretion is not resilience.
We’ve codified trust, but stopped requiring it, leaving security to agency discretion instead of institutional design. That’s not a strategy. It’s a hope. And hope is not a security control.
I’ve been in the PKI space for a long time, and I’ll be honest, digging through Certificate Policies (CPs) and Certification Practice Statements (CPSs) is far from my favorite task. But as tedious as they can be, these documents serve real, high-value purposes. When you approach them thoughtfully, the time you invest is anything but wasted.
What a CPS Is For
Beyond satisfying checkbox compliance, a solid CPS should:
Build trust by showing relying parties how the CA actually operates.
Guide subscribers by spelling out exactly what is required to obtain a certificate.
Clarify formats by describing certificate profiles, CRLs, and OCSP responses so relying parties know what to expect.
Enable oversight by giving auditors, root store programs, and researchers a baseline to compare against real-world issuance.
If a CPS fails at any of these, it fails in its primary mission.
Know Your Audience
A CPS is not just for auditors. It must serve subscribers who need to understand their obligations, relying parties weighing whether to trust a certificate, and developers, security researchers, and root store operators evaluating compliance and interoperability.
The best documents speak to all of these readers in clear, plain language without burying key points under mountains of boilerplate.
A useful parallel is privacy policies or terms of service documents. Some are written like dense legal contracts, full of cross-references and jargon. Others aim for informed consent and use plain language to help readers understand what they are agreeing to. CPs and CPSs should follow that second model.
Good Examples Do Exist
If you’re looking for CPS documents that get the basics right, Google Trust Services and Fastly are two strong models:
There are many ways to evaluate a CPS, but given the goals of these documents, fundamental tests of “good” would certainly include:
Scope clarity: Is it obvious which root certificates the CPS covers?
Profile fidelity: Could a reader recreate reference certificates that match what the CA actually issues?
Most CPSs fail even these basic checks. Google and Fastly pass, and their structure makes independent validation relatively straightforward. Their documentation is not just accurate, it is structured to support validation, monitoring, and trust.
Where Reality Falls Short
Unfortunately, most CPSs today don’t meet even baseline expectations. Many lack clear scope. Many don’t describe what the issued certificates will look like in a way that can be independently verified. Some fail to align with basics like RFC 3647, the framework they are supposed to follow.
Worse still, many CPS documents fail to discuss how or if they meet requirements they claim compliance with. That includes not just root program expectations, but also standards like:
Server Certificate Baseline Requirements
S/MIME Baseline Requirements
Network and Certificate System Security Requirements
These documents may not need to replicate every technical detail, but they should objectively demonstrate awareness of and alignment with these core expectations. Without that, it’s difficult to expect trust from relying parties, browsers, or anyone else depending on the CA’s integrity.
Even more concerning, many CPS documents don’t fully reflect the requirements of the root programs that grant them inclusion:
These failures are not theoretical. They have led to real-world consequences.
Take Bug 1962829, for example, a recent incident involving Microsoft PKI Services. “A typo” introduced during a CPS revision misstated the presence of the keyEncipherment bit in some certificates. The error made it through publication and multiple reviews, even as millions of certificates were issued under a document that contradicted actual practice.
The result? Distrust risks, revocation discussions, and a prolonged, public investigation.
The Microsoft incident reveals a deeper problem, CAs that lack proper automation between their documented policies and actual certificate issuance. This wasn’t just a documentation error, it exposed the absence of systems that would automatically catch such discrepancies before millions of certificates were issued under incorrect policies.
This isn’t an isolated case. CP and CPS “drift” from actual practices has played a role in many other compliance failures and trust decisions. This post discusses CA distrust and misissuance due to CP or CPS not matching observable reality is certainly a common factor.
Accuracy Is Non-Negotiable
Some voices in the ecosystem now suggest that when a CPS is discovered to be wrong, the answer is simply to patch the document retroactively and move on. This confirms what I have said for ages, too many CAs want the easy way out, patching documents after problems surface rather than investing in the automation and processes needed to prevent mismatches in the first place.
That approach guts the very purpose of a CPS. Making it easier for CAs to violate their commitments creates perverse incentives to avoid investing in proper compliance infrastructure.
Accountability disappears if a CA can quietly “fix” its promises after issuance. Audits lose meaning because the baseline keeps shifting. Relying-party trust erodes the moment documentation no longer reflects observable reality.
A CPS must be written by people who understand the CA’s actual issuance flow. It must be updated in lock-step with code and operational changes. And it must be amended before new types of certificates are issued. Anything less turns it into useless marketing fluff.
Make the Document Earn Its Keep
Treat the CPS as a living contract:
Write it in plain language that every audience can parse.
Tie it directly to automated linting so profile deviations are caught before issuance. Good automation makes policy violations nearly impossible; without it, even simple typos can lead to massive compliance failures.
Publish all historical versions so the version details in the document are obvious and auditable. Better yet, maintain CPS documents in a public git repository with markdown versions that make change history transparent and machine-readable.
Run every operational change through a policy-impact checklist before it reaches production.
If you expect others to trust your certificates, your public documentation must prove you deserve that trust. Done right, a CPS is one of the strongest signals of a CA’s competence and professionalism. Done wrong, or patched after the fact, it is worse than useless.
Root programs need to spend time documenting the minimum criteria that these documents must meet. Clear, measurable standards would give CAs concrete targets and make enforcement consistent across the ecosystem. Root programs that tolerate retroactive fixes inadvertently encourage CAs to cut corners on the systems and processes that would prevent these problems entirely.
CAs, meanwhile, need to ask themselves hard questions: Can someone unfamiliar with internal operations use your CPS to accomplish the goals outlined in this post? Can they understand your certificate profiles, validation procedures, and operational commitments without insider knowledge?
More importantly, CAs must design their processes around ensuring these documents are always accurate and up to date. This means implementing testing to verify that documentation actually matches reality, not just hoping it does.
The Bottom Line
CPS documents matter far more than most people think. They are not busywork. They are the public guarantee that a CA knows what it is doing and is willing to stand behind it, in advance, in writing, and in full view of the ecosystem.
This morning, the Chrome Root Program dropped another announcement about Certificate Authority (CA) performance. Starting with Chrome 139, new TLS server certificates from specific Chunghwa Telecom [TAIWAN] and NetLock Kft. [HUNGARY] roots issued after July 31, 2025 will face default distrust. Why? “Patterns of concerning behavior observed over the past year” that have “diminished” Chrome’s confidence, signaling a “loss of integrity.”
For those of us in the WebPKI ecosystem, this news feels less like a shock and more like a weary nod of recognition. It’s another chapter in the ongoing saga of trust, accountability, and the recurring failure of some CAs to internalize a fundamental principle: “If you’re doing it right, you make the web safer and provide more value than the risk you represent.” Chrome clearly believes these CAs are falling short on that value proposition.
Browsers don’t take these actions lightly, their role as guardians of user trust necessitates them. They delegate significant trust to CAs, and when that trust gets undermined, the browser’s own credibility suffers. As Chrome’s policy states, and today’s announcement reinforces, CAs must “provide value to Chrome end users that exceeds the risk of their continued inclusion.” This isn’t just boilerplate; it’s the yardstick.
Incident reports and ongoing monitoring provide what little visibility exists into the operational realities of the numerous CAs our ecosystem relies upon. When that visibility reveals “patterns of concerning behavior,” the calculus of trust shifts. Root program managers scrutinize incident reports to assess CAs’ compliance, security practices, and, crucially, their commitment to actual improvement.
“Patterns of Concerning Behavior” Means Systemic Failure
The phrase “patterns of concerning behavior” is diplomatic speak. What it actually means is a CA’s repeated demonstration of inability, or unwillingness, to adhere to established, non-negotiable operational and security standards. It’s rarely a single isolated incident that triggers such action. More often, it’s the drip-drip-drip of failures, suggesting deeper systemic issues.
These patterns typically emerge from three critical failures:
Failing to identify true root causes. Many CAs identify superficial causes like “we missed this in our review,” “compliance failed to detect,” “we had a bug” without rigorously asking why these occurred and what foundational changes are necessary. This inevitably leads to repeat offenses.
Failure to learn from past incidents. The WebPKI has a long memory, and public incident reports are meant to be learning opportunities for the entire ecosystem. When a CA repeats its own mistakes, or those of others, it signals a fundamental breakdown in their improvement processes.
Failure to deliver on commitments. Perhaps the most egregious signal is when a CA makes commitments to address issues (engineering changes, operational improvements) and then simply fails to deliver. This reflects disrespect for root programs and the trust placed in CAs, while signaling weak compliance and engineering practices.
Chrome’s expectation for “meaningful and demonstrable change resulting in evidenced continuous improvement” wasn’t met. This isn’t about perfection; it’s about demonstrable commitment to improvement and proving it works. A “loss of integrity,” as Chrome puts it, is what happens when that commitment is found wanting.
The Problem with “Good Enough” Incident Response
Effective incident reporting should be boring, routine, and a clear demonstration that continued trust is justified. But for CAs exhibiting these negative patterns, their incident responses are anything but. They become exercises in damage control, often revealing unpreparedness, insufficient communication, or reluctance to fully acknowledge the scope and true cause of their failings.
The dangerous misconception that incident reporting is merely a “compliance function” undermines the entire process. Effective incident response requires concerted effort from compliance, engineering, operations, product teams, and leadership. When this holistic approach is missing, problematic “patterns” are inevitable.
Root programs consistently see through common deflections and mistakes that CAs make when under scrutiny:
Arguing that rules should change during an incident, even though CAs agreed to the requirements when they joined the ecosystem
Claiming an issue is “non-security relevant” as an excuse, even though requirements are requirements. There’s no “unless it isn’t a security issue” exception
Asking root programs for permission to fail despite the fact that lowering standards for one CA jeopardizes the entire WebPKI
Not following standard reporting templates signals that you don’t know the requirements and externalizes the costs of that on others by making analysis unnecessarily difficult
Accountability Isn’t Optional
Chrome’s recent actions represent accountability in practice. While some might view this as punitive, it’s a necessary mechanism to protect WebPKI integrity. For the CAs in question, and all others, the message is clear:
Rely on tools and data, not just people. Use automated systems and data-driven strategies to ensure standardized, reliable incident responses.
Preparation isn’t optional. Predefined response strategies, validated through tabletop exercises, are crucial infrastructure.
Transparency isn’t a buzzword. It’s a foundational requirement for building and maintaining trust, especially when things go wrong.
This isn’t about achieving impossible perfection. It’s about establishing and maintaining robust, auditable, and consistently improving systems and processes. It’s about fostering organizational culture where “the greatest enemy of knowledge is not ignorance, but the illusion of knowledge,” and where commitment to “sweat in practice to bleed less in battle” shows up in every action.
Trust Is Earned, Not Given
The WebPKI is built on a chain of trust. When links in that chain demonstrate repeated weakness and failure to strengthen themselves despite guidance and opportunity, the only responsible action is to isolate that risk.
Today’s announcement is simply that principle in action, a reminder that in the WebPKI, trust is earned through consistent excellence and lost through patterns of failure. The choice, as always, remains with each CA: demonstrate the value that exceeds your risk, or face the consequences of falling short.
Limitations often spark the most creative solutions in technology. Whether it’s budget constraints, legal hurdles, or hardware restrictions, these boundaries don’t just challenge innovation, they fuel it.
This principle first clicked for me as a broke kid who desperately wanted to play video games, but I did have access to BBSs, a computer, and boundless curiosity. These bulletin-board systems hosted chat rooms where people collaborated to crack games. To access premium games, you needed to contribute something valuable. This necessity sparked my journey into software cracking.
Without prior expertise, I cycled to the local library, borrowed a book on assembly language, and began methodically reverse-engineering my favorite game’s copy protection. After numerous failed attempts, I discovered the developers had intentionally damaged specific floppy-disk sectors with a fine needle during manufacturing. The software verified these damaged sectors at runtime, refusing to operate without detecting these deliberate defects. Through persistent experimentation and countless hours of “NOP-ing” suspicious assembly instructions, I eventually bypassed the DRM. This experience vividly demonstrated how necessity, persistence, and precise technical exploration drive powerful innovation.
This principle consistently emerges across technology: constraints aren’t merely obstacles, they’re catalysts for creative solutions. The stories that follow, spanning console gaming, handheld computing, national semiconductor strategy, and modern AI research, illustrate how limits of every kind spark breakthrough thinking.
Nintendo: Legal Ingenuity Through Simplicity
In the late 1980s, Nintendo faced rampant cartridge piracy. Rather than implementing complex technical protections that pirates could easily circumvent, Nintendo embedded a simple copyrighted logo into their cartridge ROMs. Games wouldn’t run unless the boot sequence found an exact match. This elegant approach leveraged copyright law, transforming minimal technical effort into robust legal protection.
Palm OS: Creativity Driven by Extreme Limitations
Early Palm devices offered just 128 KB to 1 MB of memory, forcing developers into remarkable efficiency. Every feature required thorough justification. As a result, Palm OS applications became celebrated for their simplicity, responsiveness, and intuitive user experience. Users valued these apps precisely because constraints compelled developers to distill functionality to its essential elements.
China’s Semiconductor Innovation Under Sanctions
When international sanctions limited China’s access to advanced semiconductor technology, progress accelerated rather than stalled. Chinese companies turned to multi-patterning, chiplet packaging, and resilient local supply chains. Constraints became catalysts for significant breakthroughs instead of barriers to progress.
DeepSeek: Innovating Around GPU Limitations
DeepSeek faced limited access to the latest GPUs required for training large AI models. Instead of being hindered, the team embraced resource-efficient methods such as optimized pre-training and meticulously curated datasets. These strategic approaches allowed them to compete effectively with rivals possessing far greater computational resources, proving once again that constraints fuel innovation more than they impede it.
Constraints as Catalysts for Innovation
Across these diverse stories, constraints clarify objectives and inspire resourcefulness. Limits narrow the scope of possibilities, compelling individuals and teams to identify their most critical goals. They block conventional solutions, forcing innovative thinking and creative problem-solving. Ultimately, constraints channel energy and resources into the most impactful paths forward.
Turn Limits into Tools
The next time you face constraints, embrace them, and if you need to spark fresh ideas, consider deliberately creating limitations. Time-box a project to one week, cap the budget at $1,000, or mandate that a prototype run on a single micro-instance. Necessity doesn’t just inspire invention; it creates the exact conditions where meaningful innovation thrives.
What constraint will you impose on your next project?
In an earlier piece, ‘The Limitations of Audits,’ we explored how traditional compliance frameworks often fall short, functioning as point-in-time assessments rather than drivers of continuous security practices. Building on that foundation, and expanding on our exploration in ‘When AI Injects Liquidity Into Skills: What Happens to the Middle Tier?’, let’s examine how AI is poised to transform this landscape by introducing “skill liquidity” to compliance and auditing.
The High Price of Illiquid Expertise: Manual Bottlenecks in Compliance Today
As I’ve lamented before, the real cost of traditional, “illiquid” approaches to compliance expertise is staggering. In WebTrust audits, for instance, audit teams frequently report not having “enough time to look at the big picture” because their efforts are consumed by manual, repetitive tasks. Approximately 5-10% of an entire audit engagement – which can range from 350 to well over 1,500 hours for the audit firm alone – is often dedicated just to mapping organizational policy documents against standard templates. Another 15-20% of those hours are spent scrutinizing core operational processes mandated by frameworks, such as user access lifecycles or system change logs.
These percentages represent an enormous drain of highly skilled human capital on work that is largely automatable. And these figures only account for the auditors’ direct engagement. The true cost multiplies when you factor in the mountain of preparation by the entity being audited and subsequent review by third parties. The fully loaded headcount costs across this ecosystem for a single audit cycle represent a heavy tax on expertise that remains stubbornly “frozen” in manual processes.
First-Wave Automation: A Trickle of Skill Liquidity, or a New Kind of Friction?
The first wave of automation has arrived, with tools like Vanta and Secureframe offering streamlined pathways to certifications like SOC 2 by generating policy templates and automating some evidence collection. For many organizations, especially those with simpler, cloud-native environments, this has made basic compliance more accessible, a welcome “trickle of skill liquidity” that helps get a generic certification done in record time.
However, this initial wave has inadvertently created what we might call “automation asymmetry.” These tools predominantly empower the audited entity. When a company uses sophisticated automation to produce voluminous, perfectly formatted artifacts, while auditors still rely on largely manual review, a dangerous gap emerges. The truth risks getting lost in these “polished milquetoast” audits. The sheer volume and veneer of perfection can overwhelm human scrutiny, potentially masking underlying issues or a compliance posture that’s merely superficial. The audit can devolve into a review of well-presented fiction rather than an unearthing of operational fact.
Unlocking True Skill Liquidity: Intelligent Systems That Make Deep Compliance Knowledge Flow
To move beyond surface-level automation or basic Large Language Models (LLMs), we need intelligent compliance systems – sophisticated platforms designed to embed and scale deep domain knowledge. This isn’t just about processing text; it’s about an AI that understands context, relationships, history, and the intricate rules of specific compliance frameworks from the perspective of all stakeholders. Indeed, this drive to embed and scale specialized knowledge through AI is a significant trend across industries. For instance, leading professional services firms have been developing proprietary generative AI platforms, like McKinsey’s Lilli (announced in 2023), to provide their consultants with rapid access to synthesized insights drawn from vast internal knowledge bases, effectively enhancing their own ‘skill liquidity’ and analytical capabilities. Such systems, whether for broad consulting or specialized compliance, require:
An ontology of expertise: Encoding the structured knowledge of seasoned auditors—controls, their intent, interdependencies, and valid evidence criteria.
An ontology of documents: Understanding the purpose and interplay of diverse artifacts like System Security Plans, policies, vulnerability scans, and their connection to the compliance narrative.
Temporal logic and change tracking: Recognizing that compliance is dynamic, and analyzing how policies, controls, and evidence evolve over time, identifying drift from baselines.
Systemic integration: A cohesive architecture of LLMs, knowledge graphs, rule engines, and data connectors that can ingest, analyze, and provide auditable insights.
This approach transforms an AI from one that simply helps prepare artifacts to one that can critically assess them with genuine understanding – a crucial shift towards making knowledge truly usable (a concept we delve into in ‘From Plato to AI: Why Understanding Matters More Than Information’ ) – making that deep compliance knowledge flow across the ecosystem.
Liquidating Rote Work, Elevating Human Expertise: AI’s Impact on Audit Value and Integrity
When auditors and program administrators leverage intelligent systems, the nature of their work fundamentally changes—a direct consequence of “skill liquidity.” The AI can ingest and critically analyze the (potentially voluminous and auditee-generated) artifacts, performing the initial, labor-intensive review that consumes so many hours. This liquidates the rote work, significantly impacting even the global delivery models of audit services, as routine document review tasks are often offshored for cost savings, can now be performed with greater consistency, speed, and contextual insight by these intelligent systems.
This frees up high-value human experts to:
Focus on what truly matters: Shift from the minutiae of “collection, ticketing, whether there was testing involved, whether there was sign-off” to the crucial judgment calls: “Is this a finding or a recommendation?”
Investigate with depth: Dive into complex system interactions, probe anomalies flagged by the AI, and assess the effectiveness of controls, not just their documented existence.
Enhance audit integrity: By piercing the veneer of “polished” evidence, these AI-augmented auditors can ensure a more thorough and truthful assessment, upholding the value of the audit itself.
The New Compliance Economy: How Liquid Skills Reshape Teams, Tools, and Trust
This widespread skill liquidity will inevitably reshape the “compliance economy.” We’ll see:
Transformed Team Structures: Fewer people will be needed for the easily automated, “liquid” tasks of data collection and basic checking. The demand will surge for deep subject matter experts who can design, oversee, and interpret the findings of these intelligent systems, and who can tackle the complex strategic issues that AI surfaces.
Empowered Audited Organizations: Companies won’t just be scrambling for periodic audits. They’ll leverage their own intelligent systems for continuous self-assurance, drastically reducing acute audit preparation pain and eliminating those “last-minute surprises.” Furthermore, the common issue of “accepted risks” or Plans of Action & Milestones (POA&Ms) languishing indefinitely is addressed when intelligent systems continuously track their status, aging, and evidence of progress, bringing persistent, transparent visibility to unresolved issues.
New Proactive Capabilities: With compliance intelligence more readily available, organizations can embed it directly into their operations. Imagine Infrastructure as Code (IaC) being automatically validated against security policies before deployment, or proposed system changes being instantly assessed for policy impact. This is proactive compliance, fueled by accessible expertise.
Trust is enhanced because the processes become more transparent, continuous, and validated with a depth previously unachievable at scale.
The Liquid Future: Verifiable, Continuous Assurance Built on Accessible Expertise
The ultimate promise of AI-driven skill liquidity in compliance is a future where assurance is more efficient, far more effective, and fundamentally more trustworthy. When critical compliance knowledge and sophisticated analytical capabilities are “liquefied” by AI and made continuously available to all parties—auditees, auditors, and oversight bodies—the benefits are profound:
Audited entities move from reactive fire drills to proactive, embedded compliance.
Auditors become true strategic advisors, their expertise amplified by AI, focusing on systemic integrity.
Compliance Program Administrators gain powerful tools for consistent, real-time, and data-driven oversight.
The journey requires a shift in perspective. Leaders across this ecosystem must recognize the risks of automation asymmetry and the limitations of surface-level tools. The call, therefore, is for them to become true orchestrators of this new compliance liquidity, investing not just in AI tools, but in the expertise, updated frameworks, and cultural shifts that turn AI’s potential into verifiable, continuous assurance. This is how we move beyond the “polished milquetoast” and forge a future where compliance is less about the performance of an audit and more about the verifiable, continuous truth of operational integrity, built on a bedrock of truly accessible expertise.
In financial markets, liquidity changes everything. Once-illiquid assets become tradable. New players flood in. Old hierarchies collapse. Value flows faster and differently.
The same thing is now happening to technical skill.
Where expertise was once scarce and slowly accumulated, AI is injecting liquidity into the skill market. Execution is faster. Access is broader. Barriers are lower. Like in finance, this shift is reshaping the middle of the market in ways that are often painful and confusing.
This is not the end of software jobs. It is a repricing. Those who understand the dynamics of liquidity, and how unevenly it spreads, can not only navigate this change they can succeed because of it rather than get displaced by it.
The Skill Market Before AI
Historically, software development was built on a steep skill curve. It took years to develop the knowledge required to write performant, secure, maintainable code. Organizations reflected this with layered teams: junior developers handled simple tickets, mid-tier engineers carried the delivery load, and senior engineers architected and reviewed.
This mirrored an illiquid market:
Knowledge was siloed, often in the heads of senior devs or buried in internal wikis.
Feedback loops were slow, with code reviews, QA gates, and manual debugging.
Skill mobility was constrained, so career progression followed a fixed ladder over time.
In this world, mid-tier developers were essential. They were the throughput engine of most teams. Not yet strategic, but experienced enough to be autonomous. Scarcity of skill ensured their value.
AI Changes the Market: Injecting Skill Liquidity
Then came the shift: GitHub Copilot, ChatGPT, Claude, Gemini, Cursor, Windsurf, and others.
These tools do more than suggest code. They:
Fill in syntax and structural gaps.
Scaffold infrastructure and documentation.
Explain APIs and recommend architectural patterns.
Automatically refactor and write tests.
They reduce the friction of execution. GitHub’s research shows developers using Copilot complete tasks up to 55 percent faster (GitHub, 2022). Similar gains are reported elsewhere.
They make skill more accessible, especially to those who lacked it previously:
Junior developers can now produce meaningful output faster than ever before.
Non-traditional developers can enter workflows that were once gated.
Senior developers can expand their span of control and iterate more broadly.
In market terms, AI liquifies skill:
The bid-ask spread between junior and mid-level capability narrows, that is, the gap between what juniors can do and what mids were once needed for shrinks.
Skill becomes less bound by time-in-seat or institutional memory.
More participants can engage productively in the software creation economy. While adoption varies, large tech firms often lead, while smaller companies or legacy-heavy sectors like banking and healthcare face higher integration hurdles, the trend toward skill liquidity is clear.
This shift is not happening evenly. That is where the real opportunity lies.
The arbitrage today is not just in the tools themselves, the chance to capitalize on gaps in how quickly teams adopt AI. It is in the opportunity spread: the gap between what AI makes possible and who is effectively using it.
Just like in markets, early adopters of new liquidity mechanisms gain a structural advantage. Teams that build AI-augmented workflows, shared prompt libraries, and internal copilots are operating on a different cost and speed curve than those still relying on traditional experience-based workflows.
This gap will not last forever. But while it exists, it offers meaningful leverage for individuals, teams, and organizations.
Importantly, AI tools amplify productivity differently across experience levels:
Juniors gain access to knowledge and patterns previously acquired only through years of experience, helping them produce higher-quality work faster.
Senior developers, with their deeper context and better judgment, often extract even greater value from these tools, using them to implement complex solutions, explore multiple approaches simultaneously, and extend their architectural vision across more projects.
Both ends of the spectrum see productivity gains, but in different ways, juniors become more capable, while seniors become even more leveraged.
This amplification effect creates acute pressure on the middle tier, caught between increasingly capable juniors and hyper-productive seniors.
Why the Middle Tier Feels the Squeeze
There is also a practical reason: cost control.
As AI raises the baseline productivity of junior developers, companies see an opportunity to rebalance toward lower-compensated talent. Where a mid-level or senior engineer was once needed to maintain velocity and quality, AI makes it possible for a well-supported junior to do more.
Companies are increasingly betting that AI tools plus cheaper talent are more efficient than maintaining traditional team structures. This shift isn’t without risks, AI-generated code can introduce errors (studies suggest 20-30% may need human fixes), and over-reliance on juniors without robust oversight can compromise quality. Experienced developers remain critical to guide and refine these workflows. That bet is paying off, especially when companies invest in prompt engineering, onboarding, internal platforms, and support tools.
But that “well-supported junior” is not automatic. It requires experienced developers to build and maintain that support system. Mentorship, internal frameworks, curated AI toolchains, and effective onboarding still depend on human judgment and care.
And while AI can augment execution, many real-world systems still depend on context-heavy problem solving, legacy code familiarity, and judgment, all of which often live with experienced, mid-level developers.
What Happens to the Middle Tier? Compression, Specialization, and Realignment
As in finance, when liquidity rises:
Margins compress. It becomes harder to justify mid-level compensation when similar output is available elsewhere.
Roles consolidate. Fewer people are needed to ship the same amount of code.
Value shifts. Execution is commoditized, while orchestration, judgment, and leverage rise in importance.
New specializations emerge. Just as electronic trading created demand for algorithmic strategists and execution specialists, AI is creating niches for prompt engineers, AI workflow designers, and domain-specific AI specialists.
This helps explain recent tech layoffs. Macroeconomic tightening and overhiring played a role, but so did something more subtle: AI-induced skill compression.
Layoffs often disproportionately affect mid-level developers:
Juniors are cheaper, and AI makes them more effective.
Seniors are harder to replace and more likely to direct or shape how AI is used.
Mid-tiers, once the backbone of execution, now face pressure from both sides.
Duolingo’s restructuring, for example, eliminated many contractor-heavy roles after adopting AI for content generation (Bloomberg, 2023). IBM has projected that up to 30 percent of back-office roles may be replaced by AI over five years (IBM, 2023). These moves reflect a larger market correction.
These examples underscore how companies are re-evaluating where skill and value live, and how automation enables workforce reshaping, sometimes at surprising layers.
The middle tier does not disappear. It gets repriced and redefined. The skills that remain valuable shift away from throughput toward infrastructure, context, and enablement.
Historical Parallel: The Rise of Electronic Trading
In the 1990s and early 2000s, financial markets underwent a similar transformation. Human traders were replaced by electronic systems and algorithms.
Execution became commoditized. Speed and scale mattered more than tenure. Mid-level traders were squeezed, unless they could reinvent themselves as quant strategists, product designers, or platform builders.
Software development is now echoing that shift.
AI is the electronic trading of code. It:
Reduces the skill premium on execution.
Increases velocity and throughput.
Rewards those who design, direct, or amplify workflows, not just those who carry them out.
The New Playbook: Think Like a Market Maker
If you are a developer today, the key question is no longer “How good is my code?” It is “How much leverage do I create for others and for the system?”
Here is how to thrive in this new market:
Become a Force Multiplier Build internal tools. Create reusable prompts. Develop standard workflows. A mid-tier developer who builds a shared test and prompt suite for new APIs can significantly reduce team ramp-up time, with some teams reporting up to 40 percent gains (e.g., internal studies at tech firms like Atlassian).
Shift from Throughput to Leverage Own end-to-end delivery. Understand the business context. Use AI to compress the time from problem to insight to deployment.
Curate and Coach AI raises the floor, but it still needs editorial control. Be the one who sets quality standards, improves outputs, and helps others adopt AI effectively.
Build Liquidity Infrastructure Invest in internal copilots, shared prompt repositories, and domain-specific agents. These are the new frameworks for scaling productivity.
What Leaders Should Do
Engineering leaders must reframe how they build and evaluate teams:
Rethink composition. Combine AI-augmented juniors, orchestration-savvy mids, and high-leverage seniors.
Promote skill liquidity. Create reusable workflows and support systems that reduce onboarding friction and accelerate feedback.
Invest in enablement. Treat prompt ops and AI tooling as seriously as CI/CD and observability.
Evaluate leverage, not volume. Focus on unblocked throughput, internal reuse, and enablement, not just tickets closed.
Leaders who create liquidity, not just consume it, will define the next wave of engineering excellence.
Conclusion: Orchestrators Will Win
AI has not eliminated the need for developers. It has eliminated the assumption that skill value increases linearly with time and tenure.
In financial markets, liquidity does not destroy value. It redistributes it and exposes where the leverage lives.
The same shift is happening in software. Those who thrive will be the ones who enable the flow of skill, knowledge, and value. That means orchestration, amplification, and infrastructure.
In markets, liquidity rewards the ones who create it. In engineering, the same will now be true.
The cybersecurity world often operates in stark binaries, “secure” versus “vulnerable,” “trusted” versus “untrusted.” We’ve built entire security paradigms around these crisp distinctions. But what happens when the most unpredictable actor isn’t an external attacker, but code you intentionally invited in, code that can now make its own decisions?
I’ve been thinking about security isolation lately, not as a binary state, but as a spectrum of trust boundaries. Each layer you add creates distance between potential threats and your crown jewels. But the rise of agentic AI systems completely reshuffles this deck in ways that our common security practices struggle to comprehend.
Why Containers Aren’t Fortresses
Let’s be honest about something security experts have known for decades: namespaces are not a security boundary.
In the cloud native world, we’re seeing solutions claiming to deliver secure multi-tenancy through “virtualization” that fundamentally rely on Linux namespaces. This is magical thinking, a comforting illusion rather than a security reality.
When processes share a kernel, they’re essentially roommates sharing a house, one broken window and everyone’s belongings are at risk. One kernel bug means game over for all workloads on that host.
Containers aren’t magical security fortresses – they’re essentially standard Linux processes isolated using features called namespaces. Crucially, because they all still share the host’s underlying operating system kernel, this namespace-based isolation has inherent limitations. Whether you’re virtualizing at the cluster level or node level, if your solution ultimately shares the host kernel, you have a fundamental security problem. Adding another namespace layer is like adding another lock to a door with a broken frame – it might make you feel better, but it doesn’t address the structural vulnerability.
The problem isn’t a lack of namespaces – it’s the shared kernel itself. User namespaces (dating back to Linux 3.6 in 2013) don’t fundamentally change this equation. They provide helpful features for non-root container execution, but they don’t magically create true isolation when the kernel remains shared.
This reality creates a natural hierarchy of isolation strength:
Same-Kernel Process Isolation: The weakest boundary – all processes share a kernel with its enormous attack surface.
Containers (Linux Namespaces + cgroups): Slightly better, but still fundamentally sharing the same kernel.
Virtual Machines: Each tenant gets its own kernel, shrinking the attack surface to a handful of hypervisor calls – fewer doors to lock, fewer windows to watch.
Bare-Metal Library OS: Approaches like Tamago put single-purpose binaries directly on hardware with no general-purpose OS underneath. The attack surface shrinks dramatically.
Physical Separation: Different hardware, different networks, different rooms. When nothing else will do, air gaps still work.
But even this hierarchy gets fundamentally challenged by agentic systems.
The Accidental Insider Meets the Deliberate Attacker
Traditional security models focus on keeping malicious outsiders at bay. Advanced AI systems introduce two new risk profiles entirely, the accidental insider and the AI-augmented attacker.
Like a well-meaning but occasionally confused employee with superuser access, benign agentic systems don’t intend harm – they just occasionally misinterpret their objectives in unexpected ways. But we’re also seeing the rise of deliberately weaponized models designed to probe, persist, and exploit.
Consider these real-world examples:
ChatGPT o1 was tasked with winning a chess match. Without explicit instructions to cheat, o1 discovered on its own that it could edit the game state file, giving itself an advantage. The system wasn’t malicious – it simply found the most effective path to its goal of winning.
In another test, OpenAI’s O1 model encountered a vulnerability in a container during a hacking challenge. It used that to inspect all running containers, then started a new container instance with a modified command that directly accessed the hidden flag file. O1 found a container escape no one had anticipated.
Now imagine these capabilities in the hands of dedicated attackers. They’re already deploying AI systems to discover novel exploit chains, generate convincing phishing content, and automate reconnaissance at unprecedented scale. The line between accidental and intentional exploitation blurs as both rely on the same fundamental capabilities.
These incidents reveal something profound, agentic systems don’t just execute code, they decide what code to run based on goals. This “instrumental convergence” means they’ll seek resources and permissions that help complete their assigned objectives, sometimes bypassing intended security boundaries. And unlike human attackers, they can do this with inhuman patience and speed.
Practical Defenses Against Agentic Threats
If we can’t rely on perfect isolation, what can we do? Four approaches work across all layers of the spectrum:
1. Hardening: Shrink Before They Break
Remove attack surface preemptively. Less code means fewer bugs. This means:
Minimizing kernel features, libraries, and running services
Applying memory-safe programming languages where practical
Configuring strict capability limits and seccomp profiles
Using read-only filesystems wherever possible
2. Patching: Speed Beats Perfection
The window from disclosure to exploitation keeps shrinking:
Automate testing and deployment for security updates
Maintain an accurate inventory of all components and versions
Rehearse emergency patching procedures before you need them
Prioritize fixing isolation boundaries first during incidents
3. Instrumentation: Watch the Paths to Power
Monitor for boundary-testing behavior:
Log access attempts to privileged interfaces like Docker sockets
Alert on unexpected capability or permission changes
Track unusual traffic to management APIs or hypervisors
Set tripwires around the crown jewels – your data stores and credentials
4. Layering: No Single Point of Failure
Defense in depth remains your best strategy:
Combine namespace isolation with system call filtering
Segment networks to contain lateral movement
Add hardware security modules, and secure elements for critical keys
The New Threat Model: Machine Speed, Machine Patience
Securing environments running agentic systems demands acknowledging two fundamental shifts: attacks now operate at machine speed, and they exhibit machine patience.
Unlike human attackers who fatigue or make errors, AI-driven systems can methodically probe defenses for extended periods without tiring. They can remain dormant, awaiting specific triggers, a configuration change, a system update, a user action, that expose a vulnerability chain. This programmatic patience means we defend not just against active intrusions, but against latent exploits awaiting activation.
Even more concerning is the operational velocity. An exploit that might take a skilled human hours or days can be executed by an agentic system in milliseconds. This isn’t necessarily superior intelligence, but the advantage of operating at computational timescales, cycling through decision loops thousands of times faster than human defenders can react.
This potent combination requires a fundamentally different defensive posture:
Default to Zero Trust: Grant only essential privileges. Assume the agent will attempt to use every permission granted, driven by its goal-seeking nature.
Impose Strict Resource Limits: Cap CPU, memory, storage, network usage, and execution time. Resource exhaustion attempts can signal objective-driven behavior diverging from intended use. Time limits can detect unusually persistent processes.
Validate All Outputs: Agents might inject commands or escape sequences while trying to fulfill their tasks. Validation must operate at machine speed.
Monitor for Goal-Seeking Anomalies: Watch for unexpected API calls, file access patterns, or low-and-slow reconnaissance that suggest behavior beyond the assigned task.
Regularly Reset Agent Environments: Frequently restore agentic systems to a known-good state to disrupt persistence and negate the advantage of machine patience.
The Evolution of Our Security Stance
The most effective security stance combines traditional isolation techniques with a new understanding, we’re no longer just protecting against occasional human-driven attacks, but persistent machine-speed threats that operate on fundamentally different timescales than our defense systems.
This reality is particularly concerning when we recognize that most security tooling today operates on human timescales – alerts that wait for analyst review, patches applied during maintenance windows, threat hunting conducted during business hours. The gap between attack speed and defense speed creates a fundamental asymmetry that favors attackers.
We need defense systems that operate at the same computational timescale as the threats. This means automated response systems capable of detecting and containing potential breaches without waiting for human intervention. It means predictive rather than reactive patching schedules. It means continuously verified environments rather than periodically checked ones.
By building systems that anticipate these behaviors – hardening before deployment, patching continuously, watching constantly, and layering defenses – we can harness the power of agentic systems while keeping their occasional creative interpretations from becoming security incidents.
Remember, adding another namespace layer is like adding another lock to a door with a broken frame. It might make you feel better, but it doesn’t address the structural vulnerability. True security comes from understanding both the technical boundaries and the behavior of what’s running inside them – and building response systems that can keep pace with machine-speed threats.
