We've been using client certificates at MIT for more than a decade. Many people like them. But, most people hate them. As others said, the usability is the prim

We've been using client certificates at MIT for more than a decade. Many people like them. But, most people hate them. As others said, the usability is the primary issue. The specific issues are: 1. You have to install a client certificate on every device you want to use. And, you have to keep that certificate up to date. If you use multiple web browsers (for say UI development testing) you have to install and maintain the certificate it each one. MIT currently issues client certificates with a validity period of slightly less than one year. That makes for a lot of lost time every year for students, staff, and faculty, spent re-installing client certs. 2. The certificate can be stolen just like a password. But, there is no easy way for the client to revoke a stolen certificate. Many CRL list implementations are lacking or fully absent. There for, organizations that depend on client certificate authentication typically depend on certificate expiration to re-secure compromised client accounts. (See #1 above) 3. Client certificates are not supported by all web servers. The major players support it pretty well. But, there's been a proliferation of specialized, micro, and nano web servers over the last several years. 4. You have to invest in securing the signing key for the client certificates. This usually means a decent HSM which costs on the over of $x00,000USD. At MIT for example, there is a web site where anyone can go at any time to generate a new client certificate (again, see #1). This site needs to be able to perform signatures constantly which means the signing key needs to be accessible 24/7 online some how. 5. Proxies are a problem. If you try and terminate the TLS connection early, the client certificate related operations are not "proxied back". Some proxies like HAProxy will allow you to pass back environment variables set during the client certificate authentication process. But, that is obviously not the same as having the final destination webserver performing validation. This has become much more of an issue with the invention of ClouldFlare's TLS proxying CDN. 6. If you implement logic to expire certificates at the end of a customer's subscription or enrolment period, it can cause significant headaches with processes where it would be helpful to still be able to authenticate them. For example, if a customer's subscription to your SaaS site expires and you want them to be able to review with out inadvertently sharing details of their account with others. Or, if a student has graduated but they still need to pay some unpaid parking tickets. MIT runs into this issue often due to its use of client side certificates. If you extend their certificate well beyond the end of their system authorization, you have to put a lot of complex authorization code in all of your local apps and websites. While client certificates only provide authentication and not authorization, many implementers use client certificates for both simultaneously. This is especially true when protecting web content and web sites with client certificates.