> CT has a bit of an implicit dependency on heterogeneous configurations - that at least some clients report violations, and that attackers cannot easily distinguish reporting clients from non-reporting clients.

Unless I'm misunderstanding you, this isn't really how CT works: the expectation for clients under a PKI with CT is that the presented certificate is already present in one or more logs, meaning that it's never (or more accurately, never has to be) the client actually doing the reporting. Reporting is left to separate monitoring parties.

In other words: a global adversary cannot surreptitiously use a novel CA against a particular configuration; they must first make themselves visible to one or more CT logs. Failing to do so means that their CA will be rejected outright by the client (or accepted by the client if the client doesn't do CT, but still with a loss of stealth).

I'm not sure why you're so fixated on this idea of client systems monitoring CT logs.

Operators who host infrastructure can and should be monitoring issuance in CT logs for domains they operate, which will allow them to identify and react to any unexpected issuance for those domains.

I don't think firmware updates for routers is a good example. That seems more like the kind of situation where you should actually be using your own PKI.

You can't, but a certificate that isn't logged won't work for the overwhelming majority of practical use-cases (ie any Google or Apple owned product). If you need a certificate that doesn't care about those, you perhaps don't need a publicly-trusted certificate in the first place.

In addition to what nickf said in the parallel comment, CAs have committed to CT logging as part of being included in browser trust stores. If anyone were to find and report any certificates issued by those CAs via their trusted certificates that were not in CT logs, that would be strong evidence for browsers to remove them from the trust stores, which would essentially destroy their company.