boundary/website/content/docs/credentials/index.mdx

---
layout: docs
page_title: Credential management with Boundary
description: >-
  Credential stores let you store and manage credentials in Boundary. Learn about configuring user workflows with credential management or credential injection.
---

⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
> [!IMPORTANT]  
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️

# Credentials in Boundary

When users connect to a target machine, they typically need a set of credentials for authentication. Rather than requiring users to securely store and manage credentials for every target resource, Boundary centralizes credential management to enhance security.

## Credential stores

Boundary supports credential management using [credential stores](/boundary/docs/domain-model/credential-stores), which are resources that store credentials for various targets.

There are two types of credential stores:

1. Static credential store
2. Vault credential store

Static credential stores are built into Boundary and store static credentials like username password, username password domain, or keypairs. Vault credential stores point to a HashiCorp Vault instance, which provides additional capabilities like generating short-lived dynamic credentials and integrating with external systems like Active Directory through the LDAP secrets engine.

Boundary can retrieve credentials from the credential stores and present them back to the user when they connect to targets. This workflow is referred to as **credential brokering**. Boundary can also inject credentials directly into the session on behalf of the user. This workflow is referred to as **credential injection**.


## End user workflows

End users can experience three workflows when they connect to a target. In the first workflow, when an end user connects to a target, Boundary initiates the session, but the end user must know the credentials to authenticate into the session. This workflow is available for testing purposes, but it is not recommended because it places the burden on the users to securely store and manage credentials.

The second workflow uses a feature called credential brokering, where credentials are retrieved from a credentials store and returned back to the end user. The end user then enters the credentials into the session when prompted by the target. This workflow is more secure than the first workflow since credentials are centrally managed through Boundary. For more information, refer to the the [Credential brokering](/boundary/docs/concepts/credential-management#credential-brokering) concepts page.

The third workflow uses a featured called credential injection, where credentials are retrieved from a credential store and injected directly into the session on behalf of the end user. This workflow is the most secure because credentials are not exposed to the end user, reducing the chances of a leaked credential. This workflow is also more streamlined as the user goes through a passwordless experience. For more information, refer to the [Credential injection](/boundary/docs/concepts/credential-management#credential-injection) concepts page.

The type of target you connect to also determines which credential workflows you can configure:

- **TCP targets** cannot have any injected application credentials
- **SSH targets** must have at least one injected application credential to establish the SSH connection
- **RDP targets** must have at least one injected application credential to establish the RDP connection

<Note>

RDP credential injection is currently in beta and requires HCP Boundary or Boundary Enterprise.

</Note>

For more information, refer to the [Target types](/boundary/docs/domain-model/targets#target-types) documentation.

## Credential types

Boundary supports several credential types to accommodate different authentication methods:

- **Username password**: Basic username and password authentication
- **Username password domain**: Username, password, and domain for Windows environments that use Active Directory authentication, commonly used for credential injection when connecting to an RDP target
- **SSH private key**: SSH private key authentication
- **SSH certificate**: SSH certificate-based authentication
- **JSON**: Flexible JSON-based credential storage

## Next steps

The following pages provide steps to configure static credentials using both a static credential store and a Vault credential store. You can also configure targets for either credential brokering or credential injection workflows.

- [Create a static credential store](/boundary/docs/credentials/static-cred-boundary)
- [Create a Vault credential store](/boundary/docs/credentials/static-cred-vault)
- [Configure targets with credential brokering](/boundary/docs/credentials/configure-credential-brokering)
- [Configure targets with credential injection](/boundary/docs/credentials/configure-credential-injection)

To learn more about what is supported for the RDP credential injection beta and to view known issues, refer to [RDP credential injection compatibility](/boundary/docs/credentials/rdp-testing-and-compatibility-matrix).