Identity and security
Signing in without passwords, for machines too
Starting questionHow do we get rid of static passwords in the mail infrastructure, including for automations such as the ERP system?
Result
Open
Design in testing: passkeys for people, a machine identity for every automation. A client secret would just be another password.
People sign in with a passkey or a second factor, and every automation gets its own machine identity: a rotating client certificate or a short-lived token, bound to sender and source. A client secret does not replace the password; it is just a password under another name. The design is in testing.
What we tested
People sign in through the browser with a passkey or a second factor. Every automation gets its own machine identity: a rotating client certificate or a short-lived token. That identity is bound to sender and source.
Modified third-party code is maintained as a separate fork instead of being changed inside the running container. The design is in testing.
What it means for business architecture
Machine identities are part of the identity architecture, not an operational detail. In the end a client secret is just a password under another name. Only a critical review of the design made that visible.
Lessons learned
- A design review finds the weak spots before they go live.
- A source address alone is no identity when several services share it.
- Changes made directly inside a container cannot be reproduced and are lost at the next rebuild.
- Third-party code under the AGPL comes with license obligations. They belong in the plan from day one.
- passkey
- machine identity
- identity architecture