How many times have you heard about a former contractor still having access to a company network after their contract is over? Or ex-employee whose access should have been revoked? It happens all the time, and nobody remembers to revoke the access when it's no longer needed. It's a major problem because it means people who should not be authorised can still access your resources.
Revoking authentication typically relies on manual processes and someone remembering to inform IT that access requirements have changed. It's easy to see how these are overlooked. Even with all the best intentions in the world, people will forget — it's the human factor at work!
So what can you do to remove the human factor and make sure only the right people can access your network? The answer is Automated Authentication Lifecycle Management.
What is automated authentication lifecycle management?
Automated authentication lifecycle management is a hands-off authentication flow, enabling user onboarding and user offboarding in a fully automatic way.
It's based on using digital certificates for your authentication. Whenever an administrator creates a certificate with a certain lifetime, the certificate automatically expires on its end date, and it ensures users are automatically no longer authenticated beyond that date.
For example, a school could use this automated authentication mechanism. Once the students leave the school, there is a specific end date, and the account will immediately expire the moment they leave the school. There's no need to access the data in the school anymore, so their access is revoked. But when one of the staff decides to go somewhere else, they have 30 days after that moment that they still can access the data. And this is also combined within the Active Directory or maybe the Google identity store.
Why are certificates key to automating your authentication lifecycle management?
Certificates are the only appropriate authentication method for a fully automated, hands-off approach.
It's simple, really: you have to specify the end date of the certificates. There's no way around it. You can define a user and password combination for authentication, but you don't have to set an end date. When creating certificates, you have to specify an end date, and this process prompts you to be mindful of how long you assign this certificate to this specific user? Does it need to be here for 365 days? Or do I set it for 30 days?
If somebody moves on from the organisation, administrators can remove access early. But, even if they forget, the certificate will still expire on its end date and prevent unauthorised access.
One of the real benefits here is it takes the human factor out, and nobody has to remember to go and de-authorise access. When the setup is done, it's implied that there's an end date, and then. Once the certificate access is because the certificate's validity expires, the certificates are no longer valid, and authentication cannot happen with an expired certificate.
Are there any downsides to using certificates?
Ending the access for a particular user is done upfront when the certificate is created.
As a result, there could be situations where a user needs access for longer than initially planned. This user could temporarily lose access unless someone intervenes and extends the certificate. However, this downside is not as bad as a user still having access to an environment that they should not access.
Automatic authentication lifecycle management: making life easier for you
Automating your authentication lifecycle management makes life easier for IT, giving you more control over what's happening. Feel confident that the right people have the right access level without worrying about freelancers, contractors, previous employees, or other third parties inadvertently still getting access.
We need to authenticate our users; certificate-based authentication lets us automate user access and our onboarding and offboarding process. You have full control upfront over the entire authentication process from the beginning to the end because you define the end at the beginning of your authentication. Once they expire, users will not be able to access your resources. You can set an account for indefinite, but you cannot create a certificate for an undefined time.
