Month: July 2026

ETFs and the case for directly holding cryptocurrency

For the majority of time blockchains have been around, holding cryptocurrency necessarily involved jumping through hoops and doing business with a Wild West of unknown, unregulated fintech startups that specialized in providing on/off-ramps to digital assets. Some of those emerging startups grew into household names. Others spectacularly imploded in security incidents, insider fraud or compliance scandals, taking customer balances with them— Mt Gox in 2014 and more recently FTX and Celsius in 2022. With each bull market generating outsize returns far what is available from most asset classes, this pattern of blatant fraud and security negligence would pose a unique dilemma for the next group of early-adopters contemplating digital assets. On the one hand, on-boarding with one of these platforms could unlock significant returns if the asset class continues its stratospheric rise. On the other hand, it could also result in massive losses due to operational failure of the platform, as distinct from the unavoidable investment risks from the asset losing value.

This calculus was radically altered by the 2024 introduction of Bitcoin ETFs. It would not be long before similar offerings appeared for Ethereum, Solana and Ripple. Today it is possible to trade major cryptocurrencies through garden-variety brokerage accounts that most investors already have access to. (Unless of course their brokerage turns out to be an ideologue: Vanguard decided to patronize its customer base by holding out nearly two years before granting access to these “dangerous” investment options.) This poses a question: when does it make sense to hold the underlying asset directly over holding the ETF?

Variants of this existed starting with the very first, wildly successful gold ETF, GLD by State Street in 2004. Does one stack gold coins and bullions in a vault— as late-night infomercials targeted at a certain segment urge— or is holding GLD in an investment account a better route to the same outcome?

It turns out it is easier to answer this question for digital assets. There are only a handful of situations where directly holding cryptocurrency makes sense—and in those cases, it is imperative that investors capture the optionality provided by being able to operate on the blockchain. But most retail investors under most circumstances are better off seeking exposure through an ETF.

This essay is not investment advice or even personal opsec advice on appropriate safe-keeping of digital assets. Instead we posit a hypothetical investor who has already decided to hold some digital asset in their portfolio. Their decision comes down to purchasing that cryptocurrency directly through a VASP (“virtual asset service provider”) or through an ETF wrapper. This argument is also neutral on the question of self-custody versus parking funds at the VASP. Digital assets industry has come a long way since the Mt Gox implosion or even the FTX fraud. That includes making peace with the concept of regulation, accepting as the cost of mainstream acceptance and redirecting efforts to shape the exact contours of upcoming legislation instead of avoiding it altogether. Being regulated in some capacity—NYDFS BitLicense, bank-charter or even the patchwork of 50 state money-transmitter licenses— completing SOC2 audits and publishing financials are now table-stakes. Even US regulatory frameworks are starting to catch up with 2025 signing of GENIUS bill and ongoing work on CLARITY for market structure. (On the other side of the pond, the European Union was ahead of the game as usual with MiCA.) There are still material differences in risk profile between trusting one of these companies to hold funds versus taking on that responsibility for oneself, but those trade-offs are very particular to each situation. It is a function of the third-party custodian, the opsec level of the investor, their personal comfort level with attendant responsibility and even the type of asset in question, because it determines the hardware/software options suitable for an individual or enterprise to implement self-custody.

We start by focusing on the differences between the two options, focusing on additional avenues that are enabled by direct holding that are not possible with an ETF. In the discussion that follows, we only assume the investor has access to some digital asset platform for buying and selling cryptocurrency. This could be a centralized exchange where on-boarding requires KYC or a permissionless DeFi platform mediated by smart-contracts. Where custody model makes a difference, the distinction is noted.

Unequivocal advantages:

  • 24/7 trading. Cryptocurrency markets operate around the clock. ETFs only trade during market hours 9:30-4PM. Additional extended trading is available to investors who opt-in, but “extended” does not mean around-the-clock. There is also much less liquidity available during those times and no guarantee the ETF is tracking the underlying asset accurately.
  • Access to a much larger selection of digital assets. ETFs exist for only a handful of the blue-chip currencies, those with the largest market-capitalization. Even as issuers race to the tail (or bottom?) of the distribution to market Dogecoin ETFs, they have an uphill battle trying to keep up with the proliferation of copy-cat blockchains.
  • Using cryptocurrency for payments. This can be done either by directly transferring the asset to another blockchain address or participating in more complex layer-2 solutions such as the Lightning Network for Bitcoin.
  • Participating in on-chain distributed applications (dapps) such as prediction markets or lending pools.
  • Commonly zero custody fees. Securing digital assets is one of the most expensive and operationally challenging aspects of running a cryptocurrency platform. Yet most exchanges offer basic omnibus custody—where all customer funds are pooled together into a single logical wallet— as a free service, in the expectation that trading fees will subsidize that cost. By contrast an ETF charges a management fee taken out of the assets every year.
  • Exemption from wash-sale rules. There is a good reason why December sees a spike in trading: investors can manufacture artificial losses (to reduce tax liability) by selling positions that have declined in value and buying the identical position back. Net effect: portfolio remains the same but now there exist “losses” to offset capital gains for the same tax year. This works because bitcoin and other cryptocurrencies are currently classified as property rather than as securities in the US. That same trading pattern would not work for equities, including ETFs that invest in cryptocurrency. Extensive IRS rules around wash-sales discourage economically meaningless trading. These rules apply even across multiple accounts, such as selling in an investment account and buying back the same asset in a 401K. No such restrictions apply when holding digital assets directly.

Conditional advantages— these may or may not obtain, depending on particulars:

  • Censorship resistance. True for self-custody, not necessarily true when funds are held by a centralized platform. It is increasingly common for VASPs to implement anti-money laundering (AML) including complying with the OFAC sanctioned blockchain address list. Attempting to send funds to one of these addresses will be rejected. Customers tempted to work around that by first withdrawing to a personal wallet and then routing it to a sanctioned address may be surprised to receive a brief, cryptic email from the compliance department indicating that their account is being closed.
  • Seizure resistance. Same situation; only holds for self-custody. Most reputable centralized exchanges will freeze/seize customer funds in response to a law enforcement request.
  • Faster access to funds. Again true for custody, may not always hold when digital assets are parked at a centralized exchange. Most banks and brokerages have risk limits on funds movement, such as maximum amounts that can be wired in one transaction. In theory a cryptocurrency platform could allow clients to send 100% assets to a personal wallet or a competing platform but this is not a given. In fact, because blockchain transfers are irreversible, these platforms have even more stringent risk controls to avoid losses for the customer. Because that attempt to withdraw 100% of funds looks awfully like an account takeover or perhaps a romance-scam from which the customer will never be able to recover. (Aside: the question of liability for such losses has never been formally legislated. Nor is there much in the way of case law because most disputes are forced into private arbitration. VASPs will always take the stance that it was the customer’s own actions which resulted in the loss, and therefore the customer is 100% responsible for losses.)

Looking at the disadvantages:

  • High trading fees. VASPs routinely charge 0.50% to execute a single order— and recall investors must pay this toll in both directions buying and selling in order to realize gains in dollars. By comparison, most US investors can trade ETFs for free or at worst for nominal fees on the order of cents. As noted earlier, ETFs do charge a yearly management fee which eats into returns. But competition between providers naturally leads to fee compression. Nowhere is this illustrated as dramatically as with Bitcoin ETFs: even before the first day of trading, providers were racing to outdo each other by announcing drastic reductions in management fees, including a handful that promised to charge exactly zero fees for the first year.
  • Slippage, especially for retail investors. VASPs aimed at consumers include an additional spread on top of the actual cost of the asset being purchased, especially for “buy now” type experience which abstracts away the actual order book. This is not disclosed as a trading fee and can result in execution at prices substantially differing from the prevailing market value.
  • Inefficient execution. US brokerages are free to route customer orders to different execution venues (often with surprising incentives, as in the case of pay-for-order-flow practice highlighted during the 2021 GameStop incident) but they are subject to the FINRA best-execution rule. Among other things the rule calls for due diligence in finding the most favorable— to the customer— market for fulfilling the order and prohibits introducing unnecessary middle-man . VASPs are subject to no such restriction and can have private agreements with liquidity providers that results in customers getting suboptimal execution.
  • Assumption of custody risk. Security risks apply regardless of whether the investor opts for self-custody or outsources that problem to the VASP. In the former case, the investor becomes responsible for key management: setting up a hardware wallet, making sure keys are backed up offline, carefully managing withdrawals to make sure funds are not sent to the wrong address. In the latter case, the customer is still on the hook for losses when there is an account takeover or they are socially-engineered by a scammer to voluntarily transfer funds to an address controlled by that crook. While it is possible to transfer equities such as ETFs to another brokerage account, this is a much more involved process, not to mention that it requires the crook to successfully onboard with that institution— a much higher bar than generating a new wallet address.
  • Limitations for tax-advantaged accounts. It is difficult to hold cryptocurrency directly in an individual retirement account, such as IRA or self-employed 401K. No such constraints apply to holding an ETF.
  • Inheritance complications. ETFs held at a broker have straightforward mechanism to transfer ownership to the named beneficiary. That is a mandatory consequence of the Uniform TOD Securities Registration Act in the US; it is not an optional feature for financial institutions to compete on. Only a handful of VASPs allow designating a beneficiary; most require falling back on the probate process. Self-custody makes it far more tricky. Absent advanced planning to make wallet credentials or seed-phrase backups accessible to heirs, the assets can become completely unrecoverable.

Given this background, the original question can be reframed this way: Under what conditions will the advantages of direct ownership outweigh the complications? The answer for the typical American investor with long-term horizon is: rarely.

Thrilling as 24/7 trading sounds, the adrenaline rush is lost on retail investors who are not day-trading or hoping to jump on the latest memecoin release at 4AM on a weekend. These investors will gravitate to bitcoin, ethereum and similar major chains that are already well-served by ETFs. ETF coverage today extends to almost 75% of the total market-capitalization of all digital assets. What remains on the margins are L1 assets with high-volatility and low liquidity, the equivalent of penny stocks.

Similarly this investor persona has no ax to grind with the financial system in general, no ideological fixation to pay for their cup of coffee with Lightning in some grand gesture of protest directed at The Man. They are unlikely to have Metamask installed in their browser and funded with mainnet ETH, ready to interact with Web3 applications.

As for censorship resistance or the fear of arbitrary asset seizure, that is extremely relevant—in a third-world banana republic without the rule of law, where the faction in power can use the financial system to exact revenge on the politically disfavored group. In fact, given that such regimes also have strict capital controls and rapidly depreciating currency due to misguided monetary policies beholden to the autocrat in charge, bitcoin checks all the boxes as an escape hatch. That narrative becomes much less relevant in America or most of Western Europe, notwithstanding alarmist rhetoric from certain quarters that would have been very familiar to Richard Hofstadter who spoke of “the paranoid style in American politics” more than 50 years ago. Unlike the prototypical banana republic, the United States does not—generally speaking— have a history of randomly confiscating assets from broad swaths of its citizenry as a routine corollary to regime change.

To be clear, there are very legitimate concerns about existing rules that grant law enforcement too much discretion, as in the guilty-until-proven-innocent model behind asset forfeiture. There is also historical precedent of the US financial system being weaponized to exact revenge on persona non grata; politically exposed individuals have found themselves in the cross-hairs of the IRS or Treasury. In fact the cryptocurrency industry itself has earned a rightful claim to the paranoid style after being singled out for debanking during Operation Chokepoint 2.0. Incidentally, self-custody would have been of no help in that well-documented attempt to jawbone an entire politically-disfavored sector: the chokepoint in question involved access to old-fashioned fiat dollar rails. SaaS vendors and employee salaries all need to be paid in dollars, not blockchain transfers. The more general point stands: neither political activists championing controversial causes nor employees of cryptocurrency startups are representative of the “average investor” contemplating a foray into digital assets. The specter of Big Government randomly seizing the family nest egg is not a that resonates for most investors in Western countries. (It is also a logically inconsistent threat model: if a government has lost all respect for private property rights, surely they can also seize land, housing and other tangible assets that can not be spirited away to the blockchain realm.)

That leaves a narrow but highly defensible set of circumstances for the blockchain version of amassing gold bullions:

  • Residing in jurisdictions without the rule of law, where arbitrary capital controls and extra-judiciary asset-seizure is a realistic threat.
  • Investing in high-volatility, low-liquidity tail-assets for which no ETF exists or is likely to exist before the initial hype-and-crash dynamic common to those assets has already played out.
  • Transacting on-chain, for example making peer-to-peer payments or engaging with Ethereum dapps.
  • Frequent trading including off-market hours, weekends and holidays.
  • Complex tax situations when loss-harvesting from declining positions— the consolation prize when number did not go up— is important.

CP

Reluctant enforcers: certificate authorities as malware police

Learning the wrong lessons from Internet Exploder [sic]

Previous posts have alluded to the role certificate authorities play— or at least are expected to play when operating effectively— in response to discovery of digitally signed malware. Part of the bargain for inclusion in the Windows code-signing ecosystem is that CAs have an obligation to revoke code-signing certificate known to have signed malicious code. This is not exactly a new, onerous condition that MSFT has foisted on certificate authorities in a bid to raise the bar. (Unlike the way Chrome monopoly was leveraged effectively to compel CAs to adopt certificate transparency, after they had been operating for decades with no such requirement.)

The idea that CAs can be enlisted to “police” the third-party software ecosystem on Windows is almost as old as the history of Authenticode. In 1996, Seattle-area developer Fred McLain decided to make a point about the danger of ActiveX controls, by writing one subversively named “Internet Exploder” [sic] riffing on the name of the MSFT browser and signed it using an Authenticode certificate from VeriSign. By modern standards, it was a measured, responsible proof-of-concept: when the control executed in a web browser, it initiated a shutdown of the PC. Nothing particularly destructive or irreversible. MSFT, stuck at the nadir of its pre-Trustworthy Computing dark-ages approach to security, was not amused. Neither was VeriSign, which promptly revoked the certificate on the grounds of breaching the subscriber agreement, sparing Microsoft any additional work or further embarrassment— thus initiating a long-running tradition of conscripting reluctant third-parties into policing the software ecosystem.

From a narrow perspective, the intervention “worked:” because Authenticode involves mandatory revocation checks, that particular ActiveX control would be flagged as untrusted and could no longer be executed. Never mind that the broader point this developer tried to make was completely missed: namely, running native code downloaded from random websites without any semblance of sandboxing is a Bad Idea™. ActiveX was a certifiably bad idea for many reasons beyond security: native code was necessarily OS and platform dependent. Even viewed as typical, knee-jerk Redmond reaction to the peril of portable Java applets in the browser— “write once, run anywhere” Sun promised, and how exactly did that turn out?— the concept made no sense when MSFT was hawking multiple operating systems (Windows 95/98 and NT4, with different kernels and significant API differences) with the “favored” OS shipping on multiple hardware architectures: Intel x86, DEC Alpha, MIPS and PowerPC.

Relics of the ActiveX trust model

While ActiveX was quickly relegated to two niches—the backwaters of enterprise “line of business” applications and the far more vibrant ecosystem of malware development— and eventually put out to pasture, its precedent of equating “signed” with “trusted” would remain a fundamental tenet of Windows. Part of the reason is the open ecosystem: unlike mobile devices which are designed from day-one as locked down appliance with centralized control over app distribution— often by multiple actors vying for influence, such as Google vs Samsung vs T-Mobile— the PC is an open platform. To this day, it is not uncommon for legitimate Windows applications to be downloaded and installed from third-party websites, an act of “side-loading” that would be considered borderline irresponsible and dangerous on Android. Without a single app-store curating selections and keeping out bad actors, trust decisions require a correspondingly open, distributed solution. Authenticode is one piece of the puzzle. Having an ecosystem of CAs trusted to issue code-signing certificates gives developers a choice of providers for sourcing their credential.

But implicit in the Authenticode model is an unstated assumption that trust is entirely a function of publisher identity. That knowing the provenance of an application is sufficient to determine whether it is safe to run that code. That premise is suspect, even in an ideal world where we posit:

  • CAs are infallible and will never issue a code-signing certificate to the wrong person
  • Software publishers have perfect opsec around key-management and will never allow a threat actor to misuse their private key.

Even under these wildly unrealistic assumptions— easily debunked by contemporary real-life examples from that era— this model breaks down. It places the burden on consumers to become experts in the competitive dynamics of the software industry. Authenticode can answer the question of who published the software, but it can not distinguish between a reputable vendor and a fly-by-night operation. Who is to say the reputable vendor will not be tempted into bundling some spyware for a price or that unknown garage-company with the strange name one day becomes the most valuable company on Earth? Brand recognition only goes so far. At best it stacks the deck towards established incumbents with familiar names, casting suspicion on software from upstarts seeking to challenge the status quo. “What kind of person names their company Google?” one can imagine a Windows user asking, while considering whether to install the Google toolbar extension for IE back in 2000.

Creative justifications for revocation

For all of the dubious premises behind equating code-signing with trust in software, it pales in comparison to the conceptual muddle behind leveraging revocation to remove that trust:

1. Revocation is not a precision instrument: it does not simply blacklist one binary, it invalidates all code signed using that certificate after the effective date of revocation. (Third-party trusted timestamps are used to establish the signing time; otherwise a malicious signer could back/future-date signatures.) If a vendor accidentally signs a back-doored version once in the middle of a sequence of ten legitimate releases, there is no way to only revoke that single instance. At best one can specify a revocation time to shield past releases; anything after the malicious sample will still become collateral damage. There is no way to achieve the opposite effect and preserve validity of latest versions while revoking older ones. That seems reasonable when focusing on the threat model of key-compromise. The implicit assumption is, if an attacker could sign using a key once, they can do so again in the future. Strangely that is less likely to hold today when code-signing certificates are required to be held in cryptographic hardware, creating a new failure mode: an attacker can get temporary access to the code-signing infrastructure to sign some unauthorized code but they can not extract the private key and walk away with it for indefinite access.

2. There is no global “do-not-issue” list that is the equivalent of the TSA No-Fly list for digital certificates. One CA revoking a developer certificate for creating malware has no effect on whether the same developer can provision another valid Authenticode certificate from another CA to sign the exact same offending code. (Or, as in the recent case of short-lived Azure Code Signing certificates appearing on malware, to obtain them from the same issuer.)

3. Stepping back: revocation was never intended as a policing mechanism on the behavior of software publishers. Let’s look at the revocation reasons standardized in RFC 5280. This document lists a closed-ended set of choices the issuer can state as the justification. This reason appears in the CRL entry and OCSP response. These are precisely:

CRLReason ::= ENUMERATED {
unspecified (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
-- value 7 is not used
removeFromCRL (8),
privilegeWithdrawn (9),
aACompromise (10) }

Nowhere in this list is an option for “behaved badly” or “wrote malware.” Such scenarios were historically outside the purview of PKI. Code-signing certificates are statements of identity. They are not merit badges awarded for ethical standards or excellence in software engineering. When McLain signed a malicious ActiveX control to make a point about Internet Explorer, he did not impersonate anyone, make false representations to VeriSign or deliberately divulge his private-key for others to misuse.

CAs commonly opt for “privilegeWithdrawn” as the putative reason when certificates are revoked for malware authorship. But historically that reason code meant something different. X509 distinguished between identity assertions and privilege assertions, with the latter encoding specific (as in, not unique) information about a person such as being employed by a particular company. This was envisioned as the grand Privilege Management Infrastructure counterpart to its better-known brethren PKI. PMI motivated the introduction of new reason codes #9 and #10. “aaCompromise” is the logical parallel to “caCompromise” but “privilegeWithdrawn” is something unique, with no equivalent in identity analog. It refers to a privilege contained in the certificate no longer applying to the grantee. With the benefit of 30 years, it is safe to say this grant vision of PMI went nowhere. In theory identity certificates can encode privilege attributes, but Authenticode never made use of that. There was no “virtuous developer” privilege to withdraw begin with.

Authentication vs authorization

There is a fundamental category error in using revocation to combat malware: certificates are intended for authentication. Whether a piece of code is allowed to execute is a question of authorization. Trying to deny authorization by withholding authentication is akin to combating crime by having the DMV deny driver’s licenses to people convicted of fraud, on the theory that it will prevent them from opening additional bank accounts to perpetrate more fraud.1 An Authenticode certificate is not a guarantee of developer integrity: if Bernie Madoff had been sentenced to writing Windows apps as part of his penance, nothing in the Authenticode issuance policies would stop a CA from issuing him a certificate. Given that CAs are not in the business of running background checks on software publishers as a gating factor prior to issuing credentials, it is strange to enlist them into an enforcement role after the fact when their customer turns out not to be an upstanding citizen.

In the case of Windows applications, there are already multiple authorization systems: SmartScreen for binary reputation, Windows Defender malware scanning and WDAC policies for enterprise enforcement. There is no reason to burden the identity system with solving emergent problems belonging to a higher layer. Tellingly, this is not done for TLS certificates: CAs are not obligated to revoke server certificates when a website is caught hosting scams. Those CAs have significant leverage: loud browser warnings for unencrypted traffic have made possession of a valid TLS certificate table-stakes for web presence. Yet we do not conscript CAs into policing the web.

Code Signing Baseline Requirements— the policies and procedures Authenticode CAs are expected to follow— solidified this responsibility on CAs without addressing the category error. 2024 CSBR changes require CAs to revoke certificates that signed “Suspect Code” within 24 hours While it is difficult to argue with demanding more accountability from CAs. CSBR are a contractual agreement between the platform owner and an open ecosystem of CAs hoping for a slice of the pie from issuing code-signing certificates. Microsoft can impose its terms on that captive audience, but contractual obligations are not X509 semantics.

CP

1 This pattern would repeat in the early 2000s with “Kids Passport,” a feature in Microsoft’s online identity platform for complying with COPPA requirements, a precursor to controversial age verification requirements being contemplated today. If a user was known to be underage, the centralized authentication system would refuse to log them into certain Microsoft sites—a clear example of denying authorization by denying authentication.

Windows revocation providers: beyond platform trust

A malleable operating system

Windows often gets a bad rap for pulling in other Microsoft technologies and services for providing functionality—think Edge defaulting to Bing. Yet the underlying design of the operating system has been historically modular to a fault, containing an abundance of extensibility hooks. These are interfaces where third-party software can augment or even entirely replace built-in operating system functionality. Common examples from the security realm include:

  • Anti-malware scan interface for leveraging third-party antivirus solutions
  • Credential providers, to allow logging into the OS using a protocol anchored in any identity provider, such as a cloud service.
  • Key Store Providers for adding new implementations of cryptographic algorithms, such as post-quantum signatures that did not ship out-of-the-box
  • Password filters for enforcing password policy and synchronization with external identity systems.

One of the lesser-known extensibility mechanisms is the ability to extend certificate verification logic by providing custom revocation providers. Windows has historically shipped a robust certificate management engine starting in the early 2000s, featuring support for the two standardized ways of revocation checking:

  1. Certificate revocation lists (“CRL”)
  2. Online Certificate Status Protocol (“OCSP.”)

But the platform also exposes a generic hook for anyone to bring their own revocation provider. At a high-level, revocation is structured as a cascade of providers in predetermined priority order. Each provider is structured as a DLL that gets loaded in process for the application invoking the X509 validation process. When CertVerifyRevocation API is called, it queries the available providers in order about the status of the given certificate. Every provider can respond in one of three ways:

  • State that the certificate is still valid. In this case the revocation check is considered complete and no other providers are queried.
  • State that it is revoked and should no longer be trusted. This also terminates the process and returns control to the caller.
  • Throw up its hands and proclaim ignorance about the state of this certificate. In that case, the process continues by querying the next provider in the sequence.

Caveats

Before discussing some applications of a custom revocation provider, it is important to cover some limitations. The most significant one is that some applications are not using the Windows cryptography API for certificate validation. Chrome and Firefox are notorious offenders in this regard, bypassing the platform capabilities in favor of their own home-brew (but at least cross-platform consistent) trust management logic for validating server TLS certificates.

The second limitation applies even when applications are “well-behaved” and invoke the platform API for trust management. Revocation checks only happen after chain building has succeeded. If a leaf certificate does not chain up to a known trust anchor, has expired or any number of other chain validity criteria fails— intermediate CA does not have the right EKU for this leaf— the process stops early. At that point, revocation checks become moot because that certificate will never be considered valid.

Finally there is the possibility that an application specifically opts out of revocation checking in the way it calls the platform API. (Note this is different from requesting offline revocation checking to avoid network latency. In that case, the system will still execute the same steps of querying providers in sequence while passing along the request to limit checks to offline sources. Of course there is no way of enforcing this— a provider can disregard the offline flag and still perform blocking network I/O.)

Use-cases

1. Supplying missing revocation status

While the above caveats seem to imply that a custom revocation provider can only reduce trust in a certificate, this is not necessarily the case. If the provider is registered to execute first, it can preempt the answer that would have been returned from the built-in Windows engine. That means in particular that it can return “not revoked” for a certificate that has in fact been revoked. It’s difficult to imagine a realistic scenario where that would actually be useful or improve security. But there is a different use-case where preempting the built-in provider makes sense: when the standard revocation checking mechanisms are not available.

Examples include:

  • The certificate has no CRL Distribution Point (CDP) or OCSP responder field present
  • That field exists but is now outdated. For example PKI administrators can change the locations where CRLs are published, but existing certificates will continue to point to the deprecated version.
  • Even if the information is accurate, revocation checks could be taking place on a system that does not have access to the designated locations. For example ADCS allows publishing CRLs to a local SMB file-share or Active Directory for clients to fetch from. While that works fine for machines located inside the corporate perimeter, those locations may not be accessible directly from external locations.

In these cases the standard CRL/OCSP path would result in an inconclusive answer to the effect that revocation information is not available. A well-designed system fails safe in that scenario: it must treat this failure mode as being equivalent to a positive revocation outcome. (Otherwise an adversary has the incentive to DDoS the revocation servers or block network traffic in hopes of trying to use a revoked credential without the destination realizing it is no longer trusted.) Absent some way of supplying a definitive “not revoked” answer, these certificates would fail validation.

A variant of this exact scenario was encountered in a high-security deployment of Active Directory Federation Services (ADFS) configured to authenticate users with client certificates. When revocation checking is enforced, ADFS would insist on revocation checks on the entire chain— not just the leaf certificate associated with the client. While those leaf certificates had perfectly functioning CRLs, the intermediate CA issuing them had no revocation mechanism. (This is not entirely uncommon, since the introduction or deprecation of an intermediate CA is an infrequent operation best handled out-of-band, instead of by publishing CRLs.) The problem is solved by a simple revocation provider that returns a predetermined result for a set of certificates identified by their thumbprint, based on registry configuration. In particular, the provider was configured to always report a clean bill of health on the intermediate CA to avoid the ADFS validation failure.

2. Post-facto name constraints

It is no secret that the infrastructure for public TLS certificates is a house-of-cards: there are over a hundred CAs distributed around the world, capable of issuing a TLS server certificate for any website— whether or not the actual owner of the website asked for it. Some of those CAs are probably well-run, with reasonable policies and procedures in place. Others may be incompetent, YOLOing their way through managing a PKI with rudimentary controls. But the worst case scenario are a handful of CAs that are known to be affiliated with or under the control of a nation state. At that point, the CA becomes a natural extension of the surveillance capabilities of that nation, able to mint certificates to intercept traffic. The main defense against such incompetence/malice is detection: Google Chrome has leveraged its monopoly position to foist certificate transparency requirements on CAs, much to their chagrin.

Interestingly the X509 standard historically had a mechanism for constraining the power of certificate authorities. Called name constraints, these are specific fields embedded in the issuer certificate that limit issuance scope. Examples of useful constraints include:

  • DNS name: Only issue for “*.mil” domains. Makes sense for a CA operated by the US Department of Defense.
  • Email address: Only issue for users with “@acme.com” email address. Applicable to an S/MIME CA operated by the Acme company.

On its face, this is a promising feature for confining potentially rogue CAs. For example a CA affiliated with the government of China should naturally be restricted to only issue for “*.cn” hostnames, corresponding to the top-level country domain for China. The restriction would prevent it from issuing a valid “google.com” certificate even if the CA wanted to. The problem is most TLS certificate authorities are completely unconstrained; historically the root programs have shied away from taking a stance on confining nation-state affiliated CAs. From the perspective of existing roots, that ship has sailed.

Luckily custom revocation providers are not bound by the diplomatic stance taken by the CA/B Forum and they need not bestow every CA under the sun with privileges to issue certificates globally. As long as the provider gets a look at the certificate, it can enforce regional boundaries. If the CA is operating within its natural TLD, the provider stays silent and allows the revocation check to fall through to the standard CRL/OCSP path. But if the CA steps out of line, it can react by reporting the certificate as revoked.

3. Generalized revocation for code-signing

Another use-case comes out of the recent malware campaign involving ScreenConnect. To recap: threat actors were leveraging ScreenConnect installers (groundhog day) signed with their own Authenticode certificate, issued by the Microsoft Entra ID CA, to get remote control over unsuspecting consumer Windows PCs.

This particular certificate authority operated by Microsoft has a pathological design pattern that renders revocation ineffective for combatting malware: it issues a series of short-lived certificates on-demand based on code-signing events, each valid for a couple of days. Imagine a defender coming across a malware sample signed by an Entra ID certificate issued to John Smith. That could be a certificate provisioned by Mr. Smith operating as the mastermind of the malware campaign or it could be a different threat actor using stolen identity documents to impersonate Mr. Smith. Either way there is good reason to believe all other code signed by this person is suspect. In these situations, the CA has an affirmative obligation to revoke those certificates. (Whether it makes sense to enlist certificate authorities in this manner to police the software ecosystem is a separate question, meriting a future post.)

That is exactly what happened to ScreenConnect in 2025. Revocation was more sporadic in the more recent campaign involving repurposed ScreenConnect installers: Microsoft appeared to act on some, but not all Entra ID certificates reported for signing malware. Not that it mattered: given the pattern of issuing multiple short-lived certificates, the John Smith character may well have dozens of other valid Authenticode certificates. Defenders can only observe some subset from the malware samples in our possession; they cannot rule out the possibility that more exist or even that John Smith still has a valid Entra ID account for obtaining future certificates.

What this calls for is a way to blacklist the entire identity instead of some particular expression of that identity embodied in a specific X509 certificate—the narrow capability CRLs and OCSP are tailored for. Custom revocation logic allows going beyond playing a whack-a-mole with serial numbers of known-bad certificates: learning the perpetrator’s identity from the distinguished name field of one certificate, we can remove trust from all certificates issued to that threat actor. That covers past, present and future issuance:

  • Past: expired certificates where signatures made during the validity period will still validate due to time-stamping
  • Present: outstanding valid certificates that have not been revoked by the issuer yet
  • Future: certificates that do not exist, but have the potential to be issued based on existing business relationship between the CA and threat actor

In fact such generalized revocation logic can even operate across certificate authorities. If Entra ID permanently blacklists this person and they have to seek Authenticode certificates from another CA, those certificates can also be reported as “revoked” by the custom provider as long as the same legal name appears in the credential.

CP