Best practices

Best practices for operating 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 for calling applications

For machine-to-machine access, the calling application uses its client_id and client_secret to request a token. The receiving service validates that bearer token and must be configured to enforce the route; it does not need a second M2M client credential for the same call.

Protect the deployment environment

Protect the hosts, deployment secrets, and administrator access that support Access Manager. Limit access to the physical or virtual machines and the secret-management systems that deliver its configuration.

Limit access to credential-management endpoints

Identity management endpoints can expose application data. Restrict access to these endpoints and keep sensitive management operations isolated from general back-office workflows.

Security recommendations

---

Use Application-to-Application flows for sensitive endpoints

For critical access such as Ledger automation, use dedicated Applications. This gives you clear control over each integration. Delete an application through the documented Identity API when it is no longer required, and handle any existing tokens or credentials through your environment’s incident-response procedure.

Use user-based credentials for manual actions

When human access is required (for debugging, operations, or support), issue per-user credentials instead of sharing client_credentials, so you can manage access and remove permissions for each person separately. End a session only through the normal logout flow with that session’s id_token_hint; it is not an administrator-targeted “log out another user” control. Reserve client_credentials for machine-to-machine applications.

Run regular access reviews for applications and permissions. 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;
• 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.