About this guide
This guide describes the highest impact changes you can make to increase account security. Each section outlines a change you can make to your processes to improve the security. The highest impact changes are listed first.
What's the risk?
Account security is fundamental to the security of your supply chain. If an attacker can take over your account on GitHub AE, they can then make malicious changes to your code or build process. So your first goal should be to make it difficult for someone to take over your account and the accounts of other members of your organization or enterprise.
Configure two-factor authentication
The best way to improve the security of your enterprise on GitHub AE is to configure two-factor authentication (2FA) on your SAML identity provider (IdP). Passwords by themselves can be compromised by being guessable, by being reused on another site that's been compromised, or by social engineering, like phishing. 2FA makes it much more difficult for your accounts to be compromised, even if an attacker has your password.
As a best practice, to ensure both security and reliable access to your account, you should always have at least two second-factor credentials registered on your account. Extra credentials ensures that even if you lose access to one credential, you won't be locked out of your account.
Connect to GitHub AE using SSH keys
There are other ways to interact with GitHub AE beyond signing into the website via your IdP. Many people authorize the code they push to GitHub with an SSH private key. For more information, see "About SSH."
Just like the password for your IdP account, if an attacker were able to get your SSH private key, they could impersonate you and push malicious code to any repository you have write access for. If you store your SSH private key on a disk drive, it's a good idea to protect it with a passphrase. For more information, see "Working with SSH key passphrases."
Another option is to generate SSH keys on a hardware security key. You could use the same key you're using for 2FA. Hardware security keys are very difficult to compromise remotely, because the private SSH key remains on the hardware, and is not directly accessible from software. For more information, see "Generating a new SSH key and adding it to the ssh-agent."
Hardware-backed SSH keys are quite secure, but the hardware requirement might not work for some organizations. An alternative approach is to use SSH keys that are only valid for a short period of time, so even if the private key is compromised it can't be exploited for very long. This is the concept behind running your own SSH certificate authority. While this approach gives you a lot of control over how users authenticate, it also comes with the responsibility of maintaining an SSH certificate authority yourself. For more information, see "About SSH certificate authorities."