When accounts and credentials are shared, it becomes very challenging to track who did what and when. Account-based access, which tends toward this kind of sharing, is fundamentally flawed because it doesn’t tie roles and privileges to individuals, making it impossible to audit or trace resource usage or security events. Worse, accounts often rely on secret-based credentials, which have a number of serious problems.

Ref. 917D-B

Think of the “surface area” of all accounts as an attack surface on which every secret represents a potential hole. At scale, in an enterprise environment, the number of secrets is gigantic. Modern enterprise infrastructure encompasses an astonishing number of entities—users, servers, APIs, applications, and the like—each with its own role, credentials, and needs for access. In these environments, every secret-based credential becomes a potential source of human error.

Ref. 5EA8-C

One can consider encryption of secrets to be a possible solution, but encryption simply shifts the attack vector from the secret being encrypted to another secret: the decryption key. This is why large scale internet companies have stopped relying on secrets entirely. Secrets simply do not scale

Ref. 78B5-D

Unfortunately, shared secrets have some bad side effects:

Ref. 5009-E

For the reasons described above, the mere presence of infrastructure secrets, encrypted or not, is now considered a security hole. Passwords, private keys, API keys, session tokens, and even browser cookies are all vulnerabilities exploitable by human error

Ref. 2E23-F

Mapping all secrets within your organization’s computing infrastructure is the first step in discovering your attack surface area. The end goal of identity-based access is to bring the attack surface area exposed by secrets down to zero.

Ref. 141C-G

A credential should be derived from identity, not the other way around. When credentials are derived from physical identity and attested by a single trustworthy authority, it makes it possible to validate identities (authenticate) and enforce access policy (authorize) for hardware, software, and people. Only then does it become possible to add and verify the context of access and allow to enforce policies specific to the roles and entitlement of each entity.

Ref. A75D-H

While most organizations do maintain a directory of employees and an inventory of computing resources, access is often provisioned in silos, resulting in duplicated or incomplete client accounts across various environments or teams. Access silos make it difficult to enforce a coherent policy.

Ref. 14AC-I

As a result, many organizations struggle with enforcing even the basic common sense rules such as “Developers must not access production data.” If the identities of developers and machines are not stored in one place, it becomes impossible at the moment of authorization to know if a client is a developer, or if a machine is a part of a production environment, or whether a machine has any data on it. When centralized identity management is implemented, each entity’s access is attached to one true identity recognizable across the entire organization. This can only happen with the establishment of a central identity store for humans and machines.

Ref. 8A54-J

Because true identity can’t be transferred, it’s necessary to create credentials that can be trusted. One approach is to create a chain of trust, where every credential leads back to a reliable, authoritative source of truth. This trusted authority must keep data about every credential and the identity it links to, and must be able to revoke credentials whenever necessary.

Ref. FE1B-K

When the DMV issues the license, it is giving you a certificate you can use not only to authenticate your identity, but prove your authorization to drive a specific class of vehicle: motorcycles, cars and large trucks require different permissions. This authorization can be upgraded, downgraded, or revoked. The credentials provided by a database administrator have the same meaning: authentication that you are who you say you are, plus revocable authorization to access the database in specific ways

Ref. 7DA4-L

It’s important to remember that the authentication and authorization represented are independent of the certificate itself. If you alter the information on the driver’s license, it no longer matches the DMV record of your identity, and the license becomes invalid. If you abuse your database privileges, they can be revoked. The ability to grant and remove authorization is central to establishing trust.

Ref. C4DD-M

Issued by a trusted authority

Ref. D6FE-N

Unlike a secret-based credential, a digital certificate provides a way to attest to an individual’s identity, whether that individual is a person, a server, an application, or some other entity. Certificates provide not only a mechanism for establishing identity, but mechanisms for granting and revoking specific authorizations and policies. The authority that issues a certificate is responsible for issuing credentials, monitoring to detect malicious misuse of trust, and helping to thwart such attempts.

Ref. CACB-O

If you can’t—or merely don’t—verify this key, you have no way of knowing whether the server is genuine, or has been planted by an attacker. This problem is called Trust on First Use. Without verifying the identifier, it’s hard to trust the OpenSSH server you are connecting to. The importance of identity to trust can’t be overstated.

Ref. E7E2-P

The other security risk in long-lived identities is that we also tend to assign long-lived credentials to these identities. By nature, we humans need some external push before we make a change. If a website doesn’t require it,, the user may never update their password. It’s the same with every other kind of infrastructure access. Engineers will probably never update credentials if not mandated to do so—not even their credentials for the primary server and databases that the whole business depends upon. In other words, the tendency is to rely on the worst security combination: the long-lived identity paired with long-lived secret-based credentials.

Ref. 1F4E-Q

All other things being equal, an ephemeral entity is more secure than a long-lived entity in some ways. If an ephemeral entity is compromised, it has the courtesy to disappear after a while, removing the threat. The DIE triad (Distributed, Immutable, and Ephemeral) is one of the best approaches modern infrastructure has to offer in terms of the next-generation security model.

Ref. 1CFC-R

Identity-based access does not rely on secret data, but uses the physical properties of hardware and biological attributes of humans instead. This drops the probability of human error in access management to zero. If every party in the access transaction has a way of asserting its true identity, then policy can be enforced without the need for secrets, opening up a secure way to ensure only authorized entities have appropriate access to protected resources

Ref. 2444-S

To implement identity-based access to infrastructure in the modern, cloud-native and highly elastic world means definitively identifying hardware. To provide machine identity, cryptographic storage systems like hardware security modules (HSM) and Trusted Platform Modules (TPM) provide secure identity storage across a variety of computing devices such as servers, desktops, and laptops.

Ref. 2CB8-T

The important principle that connects HSMs, TPMs, and human fingerprints is that true identity is stored in the physical world. None of the data making up an identity is accessible by a bash script, and none of it can be collected in a database. The obvious benefit is that true identity is never accessible for an attacker to steal or for an employee to accidentally leak.

Ref. 07AD-U

For example, the private key of a machine is stored on its HSM, and only the public key can be stored in a database. An engineer’s fingerprint is stored on their laptop’s TPM, but the TPM can produce a hash of a fingerprint signed by its private key, and that information can be stored in a database

Ref. FDC5-V

Credentials must also operate at scale, which means every credential must be pinned to physical identity and to usage context, so it cannot be reused elsewhere at a different time by a different party. This enables scale, because the probability of an error does not increase with the number of the current credentials in a computing environment. Stealing such credentials brings no benefit to an attacker.

Ref. A573-W

A certificate is the best technology we have to solve the issue of representing physical world identity with data. Certificates make it possible for every access request to be accounted for and attributed to real-world identity and authorization, without the client’s identity or credentials being vulnerable to human error, theft, or spoofing. In addition, certificates provide several other benefits:

Ref. 3A6E-X

The following sections sum up the most important tactics for moving infrastructure access towards identity-based access.

Ref. 02DA-Y

The separation of humans and machines represents another access silo, leading to vulnerability through management complexity. To help solve this problem, teams should tie credentials to identity for machines and bots, just as they do for users.

Ref. 35EA-Z

1. Introduction: The Pillars of Access

Ref. 1EA8-A

Verifying passwords is a popular authentication method, but it’s inadequate for proving identity. After all, password-based authentication merely indicates possession of the secret itself and does not prove the bearer’s identity. Authentication must get to the heart of identity, which is a more difficult task. How do you prove the true identity of a person in the digital realm?

Ref. 9EFD-B

This pattern is sometimes called “know+have+are,” and often means a password (something you know), a one-time token generated by a separate device (something you have), and our biological traits (something we are).

Ref. 46A7-C

The most vulnerable component in an information system is the peopleware: users, administrators, developers, and others who access the system. Every breach can be traced back to a human error somewhere. The complexity of working with so many different access protocols, with their associated secrets and multi-factor authentication procedures, leads people to take shortcuts: remaining logged in between sessions, re-using passwords, writing secrets down, and other bad behaviors, which increases the probability of an exploitable mistake. Often, well-intended new security measures increase the drag on the people who use them, leading them to cut corners even more to preserve some level of productivity.

Ref. C785-D

The point of identity-based access is to move away from secrets because secrets are just data and data is vulnerable to human error. True identity is not data that can be downloaded. True identity is a characteristic of the physical world. You are you. The most difficult aspect of granting access based on identity is the problem of representing physical identity digitally. Secrets tied to usernames were a futile attempt to bring user identities into the digital realm.

Ref. 80BB-E

Therefore, the two primary challenges in implementing identity-based infrastructure access are:

Ref. 7B89-F

The next question is how to transfer true identity into the digital realm, because an access system needs to interact with true identity somehow. The best currently available mechanism to safely transfer true identity into an access system is digital certificates.

Ref. 5C81-G

Certificates can be issued to machines, humans, and applications. Certificates are natively supported by common infrastructure protocols. Certificates are safer than secrets because they are far less exposed to theft and misuse. A certificate can be revoked, set to expire automatically, be issued for a single use, and pinned to a specific context (intent) and network address. As you can see, stealing a certificate is nearly pointless. The certificate chain of trust back to a certificate authority leaves only a single secret to protect—the certificate authority itself—no matter the scale of the organization. In other words, this approach scales forever without compromising security.

Ref. 9738-H

This approach is the foundation not only of providing stronger security and more convenient access for users, but dealing with challenges of scale and complexity. The approach rests on the two principles mentioned earlier: removing secrets, to eliminate human error, and zero trust, to make a pivot impossible if a breach occurs.

Ref. D619-I

This is the approach hyperscale companies have adopted. It’s not just about moving away from secrets, but moving toward digital representation of the true identities of hardware, software, and peopleware. It’s not just about encrypting all connections, but designing all infrastructure components to be safe without a firewall with no respect to the perimeter.

Ref. 82F1-J

Traditionally, infrastructure access has never been identity-based. Instead, it has relied on data associated with an identity—mainly in the form of passwords, private keys, and other secrets—which can be easily compromised, leaving critical systems open to attack

Ref. 6F96-K

difference between credentials and identity,

Ref. A3E2-L

. Simply knowing the number is not enough; the license itself must be physically present if you want to use it in the real world—to order a drink in a restaurant in the US where the legal drinking age is 21, for example, or during a traffic stop. This is a critical aspect of identity-based access: secure forms of identification must never be represented as mere data; they must be tied to physical objects. Your driver’s license can be stolen, but at least it can’t be stolen over the Internet.

Ref. 5B33-M

establishes your authorization to operate certain classes of motor vehicles.

Ref. 0577-N

That’s one reason your driver’s license expires periodically

Ref. 6C35-O

The difference boils down to one thing: the social security number is merely information you know, while the driver’s license is a physical object which also captures who you are: your face, your signature, and other attributes that make you unique. Even so, the driver’s license is imperfect. It is not you, and the photograph is not your face.

Ref. 0622-P

In other words, your true identity is not data about you, but the fact of you. Identity is an aspect of the physical world, not the world of ones and zeroes. Much of the difficulty in proving identity comes from the challenge of representing identity—who you are—without turning it into data, which is vulnerable to theft.

Ref. 7890-Q

The first time you request a database account to be provisioned, you have to establish your identity with the database administrators. Consider the possibility of a spoofing attack at this point. Theoretically, someone else could also state your name, claiming to be you, perhaps via a falsified email message. Your name or your email address are just data about your identity, after all, not your identity itself.

Ref. AE34-R

But they are different: true identity can’t be stolen or spoofed. There is only one you. Credentials are merely information about you. When someone steals your driver’s license or database password, they don’t become you, but they might be able to pretend they are you.This difference is the root of all the vulnerabilities related to access control.

Ref. 0630-S

In effect, credentials are an attempt to convert real identity, which can’t be transmitted or shared, into data, which can

Ref. 4E95-T

When people talk about identity theft, what they really mean is the theft of credentials. Because credentials are the normal way of proving identity, credential theft creates huge problems, both in the real and digital world.

Ref. E327-U

Still, accounts are a widespread way of proxying identity.

Ref. 2C75-V