The architecture and approach of Circle Access differs from a certificates in several significant ways. There are two common use cases for X.509 certificates:

1. securing emails and;
2. securing authentication for access to Web server.

We will focus here on securing email.

Securing Email

1. X.509 certificates tie identity to an email address whereas Circle ties identity to a device

The exact same certificate can (and, unless extreme measures are used) MUST be used on every device used to generate or read email for that email address. Therefore, unless secondary measures are used (such as a password on the certificate), the possession of the certificate alone is sufficient to become that email address.  Virtually all X.509 certs are password protected for this reason, which means that the use must re-type the password, or the password must be stored in a local keystore.

2. X.509 certificates have a specific lifetime whereas Circle has no required expiration

X.509 certificates can’t be used before or after the set validity time to prove identity.  While a developer can set an expiration time for Circle, there is no requirement to do so.

3. X.509 certificates are only as good as the approval/generation process whereas Circle demands external authorization for each new user

If that process is weak or compromised, then the security of every session for all users is broken. Circle, on the other hand, requires each user to perform an external authorization to that is distributed and delegated to each user to ensure their identity. There is no certificate that can be compromised or hijacked. Circle further can enforce an external very strong identity verification: a biometric scan of the user - which can be enforced on every authentication, or even continuosly. Circle also offers step up escalation to human-in-the-loop identity verification whenever desired.

While most vendors that use X.509 certificates demand proof of ownership of an email address, there are many ways that this can be spoofed. Here are just a couple of examples.

• A system admin can, of course, bypass or take over any email address if the certificates are generated within a company.  If this system admin account is hacked, then so can any attacker.
• Even without a internal system compromise, emails themselves are eminently vulnerable to many forms of spoofing and Man-in-the-Middle attacks.

With Circle Access, on the other hand, three very strong factors are used to authenticate:

1. Something you have: possession of the device.
2. Something you are: a biometric scan .
3. Something you do: perform a cryptographic validation with a unique encryption key bound to the device at the time of original authorization.

X.509 certs are by their nature archivable, which makes them vulnerable to theft and attack. Circle also supports full archiving with immutable audit trails, but without the security vulnerability

X.509 cetificates can and often are archived on generation in order to ensure that messages encrypted with a given certificate can be accessed later (if the passwords are also archived).  For certain compliance environments, this can become critical. Unfortunately, this is also a very attractive target for an attacker, since breaching this can then open ALL emails.

Circle also can archive and preserve all the contents of all Circles and Secure Capsules containing encrypted emails. In fact, this is done automatically with Circle's store-and-forward Web services and cloud server. This server, however, has NO keys - and of course no passwords since there are no credentials in the system at all. So once again, there is no central repository that an attacker can go after. Instead, the attacker must breach the individual devices which possess the keys to the Circle and Secure Capsules they were members of. This exponentially increases the cost and effort.

If a company wants to maintain a central repository of keys - for compliance reasons - it can do so within a Circle-of-Trust. This can enforce a distributed, out-of-band human-in-the-loop identity verification between users that know each other in order to release keys to open designated Circles. Again, no central authority, nothing to attack in the cloud. Even compromising a device does not help - only 'breaching' or corrupting or coercing one of the human participants will suffice. Circle's internal immutable ledger ensures, however, that in the event of even the most extreme form of attack there is an audit trail of all events and actions that occured.

X.509 Certificates Can Be Used to Protect Any Email. So Can Circle.

X.509 is supported by every significant email client, and many web-based email clients and all mail transports support it. 

Circle is not explicitly 'supported' by email clients because it does not have to be. The payload of each message and any attachments is encrypted, not the headers. So any email client and email transport system can send and deliver emails secured by Circle with no issue after a simple integration is performed.