Like with any method of authentication, SSH logins are governed by corporate IAM, which in the simplest form answers the question of: who can access and where? Usually the source of truth for this is the corporate LDAP, Active Directory (AD) in many cases, which hosts the relation between identities and their allowed locations of access. With SSH keys this landscape is however very different: there exists no such single source, but instead, authorisation information is distributed across the Unix/Linux server estate itself. If a company hosts 100 servers, then this equates to that there are 100 individual decision (or breach) points for access. As a one access can lead to another, the real figure can be much larger.
The problem many organisations face today is that their IAM solutions do not support SSH keys as a method of login. Technically speaking, the existing IAM solutions are unable to bridge the gap between numerous authorisations within a Unix/Linux server estate and the identities and authorisations found within the centrally managed AD/LDAP.