And I also have a question regarding PAM management. How does infisical access the resources to change the credentials? There must be some kind of entry point, how is this not long lived? What happens in case of disaster to the Infisical database/host? (I agree this is more 3 questions than one 😛 )

In terms of PAM account credential rotation, you link a second privileged account to do the rotation on the target account. Meaning that you have the rotating account, and another that does the rotation. The access process is different based on account type. For example, a Postgres rotation would consist of the privileged account automatically accessing the rotating account through your gateway and running a SQL command to change the password. The "long lived" part in this setup would only be the credential of the privileged rotating account. But you can solve this by having this privileged account rotate itself, or just have another account rotate it. This means there would be zero long-lived credentials. Every account credential is encrypted in the database, so a database leak would not automatically give an attacker the secrets unless they also have your environment (with the encryption key).

Ok, understood for the long lived part thank you. How about disaster recovery. How do you mitigate the risk of loosing access to machines which key was rotated after the last backup?

Infisical always stores the current key of an account even after rotation, so you can continue to access it and even read the secret (if you have permission) unless the Infisical instance itself goes down or the account in Infisical gets deleted. As you would expect, unless you backup the key elsewhere you'd be locked out of the rotated account. At that point you can try to reconcile the account using another privileged account such as administrator.

Ok, I will need to give it a shot on a selft hosted instance to clarify all this an try a few scenarios