People are not the only actors that sign in. Applications, scheduled jobs, cloud workloads and devices also need identities so systems can decide which automated requests to trust and what each one is allowed to do.
Every machine identity needs a purpose and owner
An inventory connects each service account, workload identity, certificate, token or similar credential to the application that uses it, the business service it supports and the team accountable for it. The identity should be distinguishable from a human user's account.
Ownership matters when a system is replaced, a provider relationship ends or suspicious activity appears. An unidentified credential can remain active long after its original purpose disappears because no one knows whether disabling it will interrupt a critical process.
Issuance binds the identity to a trusted workload
The bank verifies how the application or workload receives its identity and protects the underlying key, secret or token. Automated issuance can reduce manual copying and make the relationship among the workload, credential and approved environment easier to prove.
Short-lived, narrowly scoped credentials reduce dependence on static secrets stored in code or configuration files. The appropriate method depends on the architecture, but the system should not assume a request is trustworthy merely because it originates inside the bank's network.
Permissions match the exact service task
A machine identity receives only the data and actions needed for its defined function. A payment-status service may need to read selected records without receiving authority to create a payment, change a customer profile or administer the database.
Environment boundaries also matter. Development and test identities should not work in production, and separate services should not share one broad credential simply because that is easier to configure.
Credentials rotate, expire and revoke
Keys, certificates and tokens have managed lifecycles with renewal, rotation and expiration before they become weak or unexpectedly stop a service. Automation is tested so a rotation updates every legitimate dependency without preserving an old credential indefinitely.
Revocation paths let the bank respond when a credential is exposed, a workload changes or access is no longer justified. Emergency action includes understanding which services will fail and how to restore them safely with a newly trusted identity.
Behavior is monitored as well as authentication
Logs connect each automated request to the identity, resource, action, time and result. Monitoring looks for unusual locations, volumes, destinations, permission use or access outside the workload's normal operating pattern.
A valid credential can still be misused by compromised software. Effective management therefore combines authentication, least privilege, lifecycle controls, behavioral monitoring and incident response rather than treating possession of a secret as permanent proof of trust.
Read the primary material
Banking Explained prioritizes regulators, official publications and first-party announcements.