Best practices

Operate Access Manager securely — manage credentials, lock down environments, and protect identity and authorization at scale.

Access Manager holds the identity, authorization, and credentials for every protected Lerian product, which makes it one of the most sensitive pieces of your stack. Treat it as critical infrastructure and operate it with the controls below.

Credentials

---

Create credentials on both ends

If two services need to talk to each other, both must have the necessary M2M credentials created. Don’t assume symmetry. Define credentials explicitly on both sides.

Lock down the physical environment

Access Manager stores credentials locally. Anyone with access to the host can extract them. Secure the physical or virtual machine hosting the service. This is your first line of defense.

Avoid exposing endpoints that retrieve the credentials

Admins in Access Manager (via Identity) can retrieve credentials. For that reason, these endpoints should not be integrated into any back-office system. Keep sensitive operations isolated to reduce the chance of accidental exposure.

Security recommendations

---

Use Application-to-Application flows for sensitive endpoints

For critical access such as Ledger automation, use Applications. This gives you clear control over each credential. If something leaks, you can revoke or delete the Application without affecting unrelated users or services.

Use user-based credentials for manual actions

When human access is required (for debugging, operations, or support), always create user credentials using the password grant, not client_credentials. This approach lets you manage access, revoke permissions, and trigger forced logouts through the appropriate endpoint.

Implement a credentials rotation policy and run regular access reviews. This minimizes exposure and keeps access limited to authorized users.

Always enforce the principle of least privilege for both users and applications. Grant only the exact permissions each one needs.

Operational changes

---

How you change access depends on what you’re changing, and the line runs between everyday operations and platform data.

Use the management surfaces after bootstrap

After the environment is running, use Identity APIs or Lerian Console for operational access changes:

• create, update, or remove users;
• assign users to groups;
• create or delete machine-to-machine applications;
• rotate credentials;
• configure providers and MFA.

Bootstrap seed data is not a day-to-day configuration surface. Editing seed files after deployment does not reliably update an existing environment.

Ship platform permission changes as controlled updates

Built-in resources, actions, roles, groups, and permission sets are platform data. Change them through migrations or an idempotent reconciler so existing environments converge predictably.

Avoid one-off database edits and manual permission changes. They create drift between environments and make access reviews harder to trust.

See our Security Recommendations for more guidance on securing your infrastructure.