> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleria.com/llms.txt
> Use this file to discover all available pages before exploring further.

# NHI secret risk recommendations

> What each secret risk reason on the Secrets page means, why it matters, and the recommended fix, including application-specific recommendations based on vendor guidance.

The **Secrets** page (**NHI** → **Secrets**) lists the active secrets, keys, tokens, and certificates that non-human identities (NHIs) use to authenticate. Oleria marks a secret as risky when one or more risk reasons apply to it. Select a secret to open its details, then select the risk level tag (for example, **High**) next to **Risk** to see each risk reason, with a recommendation for fixing it. In the **Secrets** table, the tag lists the risk reasons only.

This page explains each risk reason, why it matters, and what Oleria recommends.

## How Oleria picks a recommendation

Every risk reason has a general recommendation that applies to any application. For some applications and secret types, Oleria shows a more specific recommendation based on the vendor's own security guidance. For example, an AWS access key with no expiration gets **Replace the access key with an IAM role.** instead of the general recommendation.

Oleria uses the most specific recommendation that matches the secret:

1. A recommendation for the secret's application and secret type.
2. The general recommendation for the risk reason.

The application-specific recommendations are listed under each risk reason below, with the vendor documentation they follow.

> [!NOTE]
>
> Expired, disabled, and revoked secrets aren't shown on the **Secrets** page, so Oleria doesn't report risks for them.

## Authenticates a high-privilege identity

The secret carries the full access of an identity that Oleria rates as high privilege: a machine or token account whose **Privilege Level** is **High**, or any other account that's an admin. A secret limited to specific scopes is checked under [Granted high-privilege scopes](#granted-high-privilege-scopes) instead.

**Why it matters:** Anyone who obtains this secret gains the identity's high-privilege access.

**Recommendation:** Cut the identity's permissions to what it uses.

| Application | Secret type | Recommendation | Vendor guidance |
| :- | :- | :- | :- |
| AWS | Access Key | Trim the IAM user's policies to what it uses. | [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) |
| AWS | Certificate | Trim the IAM user's policies to what it uses. | [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) |
| Azure | OAuth Client Secret | Remove unneeded Azure role assignments. | [Best practices for Azure RBAC](https://learn.microsoft.com/en-us/azure/role-based-access-control/best-practices) |
| Azure | Public Key Pair | Remove unneeded Azure role assignments. | [Best practices for Azure RBAC](https://learn.microsoft.com/en-us/azure/role-based-access-control/best-practices) |
| Google Cloud Platform | Public Key Pair | Apply IAM role recommendations to trim permissions. | [Best practices for using service accounts](https://docs.cloud.google.com/iam/docs/best-practices-service-accounts), [Best practices for managing service account keys](https://docs.cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys) |
| Okta | API Token | Replace with an OAuth service app with narrow scopes. | [Create an API token](https://developer.okta.com/docs/guides/create-an-api-token/main/), [Implement OAuth for Okta with a service app](https://developer.okta.com/docs/guides/implement-oauth-for-okta-serviceapp/main/) |
| Okta | Public Key Pair | Remove scopes and admin rights the app doesn't use. | [Implement OAuth for Okta with a service app](https://developer.okta.com/docs/guides/implement-oauth-for-okta-serviceapp/main/) |

## Granted high-privilege scopes

The secret is limited to specific scopes, and those scopes include high-privilege permissions.

**Why it matters:** A leaked secret grants every permission in its scopes, including high-privilege ones the integration may never use.

**Recommendation:** Reissue the secret with only the scopes it uses.

All applications use this recommendation.

## Expiring soon

The secret expires within your workspace's near-expiry window, which is 30 days by default. The **Near Expiry** tile on the **Secrets** page shows the window your workspace uses.

**Why it matters:** Integrations still using the secret stop authenticating when it expires.

**Recommendation:** Rotate the secret before it expires.

| Application | Secret type | Recommendation | Vendor guidance |
| :- | :- | :- | :- |
| Azure | OAuth Client Secret | Add a replacement credential to the app registration. | [Security best practices for app registrations](https://learn.microsoft.com/en-us/entra/identity-platform/security-best-practices-for-app-registration) |
| Azure | Public Key Pair | Add a replacement certificate to the app registration. | [Security best practices for app registrations](https://learn.microsoft.com/en-us/entra/identity-platform/security-best-practices-for-app-registration) |
| Azure | Stored Secret | Add a new secret version in Key Vault before expiry. | [Automate secret rotation in Key Vault](https://learn.microsoft.com/en-us/azure/key-vault/secrets/tutorial-rotation) |
| Google Cloud Platform | Stored Secret | Extend or remove the expiry if still needed. | [Create and manage expiring secrets](https://docs.cloud.google.com/secret-manager/docs/creating-and-managing-expiring-secrets) |
| Microsoft Entra ID | OAuth Client Secret | Add a replacement credential to the app registration. | [Add credentials to an app registration](https://learn.microsoft.com/en-us/entra/identity-platform/how-to-add-credentials), [Security best practices for app registrations](https://learn.microsoft.com/en-us/entra/identity-platform/security-best-practices-for-app-registration) |

## No expiration set

The application reports that the secret never expires. Stored secrets, such as a secret in a vault, aren't flagged for this reason: the expiry on a vault entry covers only the stored copy, so Oleria flags the credential where it's issued instead.

**Why it matters:** A secret that never expires stays valid after a leak until someone revokes it.

**Recommendation:** Set an expiry and rotate the secret regularly.

| Application | Secret type | Recommendation | Vendor guidance |
| :- | :- | :- | :- |
| AWS | Access Key | Replace the access key with an IAM role. | [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html), [Secure access keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/securing_access-keys.html) |
| AWS | Password | Replace with temporary credentials from an IAM role. | [Service-specific credentials for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_service-specific-creds.html), [API keys for AWS services](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_api_keys_for_aws_services.html) |
| AWS | Public Key Pair | Switch to git-remote-codecommit, then delete this key. | [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html), [Connect to CodeCommit with rotating credentials](https://docs.aws.amazon.com/codecommit/latest/userguide/temporary-access.html) |
| Google Cloud Platform | Access Key | Rotate the HMAC key on a schedule. | [HMAC keys](https://docs.cloud.google.com/storage/docs/authentication/hmackeys), [Manage HMAC keys](https://docs.cloud.google.com/storage/docs/authentication/managing-hmackeys), [Organization policy constraints for Cloud Storage](https://docs.cloud.google.com/storage/docs/org-policy-constraints) |
| Google Cloud Platform | Public Key Pair | Use an attached service account instead of a key. | [Best practices for managing service account keys](https://docs.cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys), [Service account credentials](https://docs.cloud.google.com/iam/docs/service-account-creds) |
| Okta | OAuth Client Secret | Rotate the client secret on a schedule. | [Manage OAuth client credentials](https://help.okta.com/en-us/content/topics/apps/oauth-client-cred-mgmt.htm), [Rotate client secrets](https://developer.okta.com/docs/guides/client-secret-rotation-key/main/) |
| Okta | Public Key Pair | Rotate the key pair on a schedule. | [Manage OAuth client credentials](https://help.okta.com/en-us/content/topics/apps/oauth-client-cred-mgmt.htm) |

## Shared across identities

The secret authenticates more than one identity.

**Why it matters:** One leaked secret compromises every identity it authenticates, and rotating it disrupts all of them at once.

**Recommendation:** Give each identity its own secret.

All applications use this recommendation.

## Not vaulted

The secret is kept by whoever uses it, outside any secrets manager.

**Why it matters:** Copies held outside a vault are hard to track and rotate, and can leak through code, config, or logs.

**Recommendation:** Move the secret into a secrets manager.

All applications use this recommendation.

> [!NOTE]
>
> Oleria raises this risk reason only when an application reports that a secret is kept outside a vault. No connected application reports this yet, so you won't see it today.

## Contact us

For questions, contact us at [support@oleria.com](mailto:support@oleria.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.