Why are API keys and certificates the typical authentication means for machines, and what is their main risk?

A machine must authenticate unattended, so it needs a secret it can use automatically: an API key (a long random shared string) or a private key with a certificate. The main risk is that this stored secret is stolen, for example from source code, a configuration file or a compromised server.

• API key: a long random string sent with each request. Simple, but it is a bearer secret: whoever copies it can use it, just like a password, and it is often accidentally committed to code repositories or logged.
• Certificate with private key: used in (mutual) TLS. The private key signs during the handshake and never travels, so intercepting traffic does not reveal it, and the certificate can expire and be revoked centrally.
• Tokens: short-lived access tokens (for example from OAuth client-credentials flows) limit the damage of a leak to minutes or hours.

Good practice therefore mirrors what makes human authenticators strong: keep the secret in protected storage (a secrets vault or hardware security module), prefer asymmetric keys over shared secrets, rotate and expire secrets automatically, and give each machine its own identity so a leak can be revoked without breaking everything.

Go deeper:

• API key (Wikipedia) — how API keys are used and the security incidents caused by leaked keys.
• Hardware security module (Wikipedia) — tamper-resistant storage for the keys machines authenticate with.