Hello. In the previous lesson, you treated job descriptions as evidence of what employers expect to see: real projects, public repositories, and reliable engineering habits. Your GitHub account will soon become the home for that proof of work, so securing it is not an administrative detail. It protects your portfolio repositories, commit history, and professional identity.
In this lesson, you will either create a professional GitHub account or secure the one you plan to use for job applications. You will enable multi-factor authentication using an authenticator app, save recovery codes safely, and choose a sensible backup approach without exposing credentials.
A professional GitHub account is both public identity and developer infrastructure
A recruiter may open your GitHub profile from a résumé link. Later, you will also use the same account to create repositories, deploy portfolio projects, collaborate, and authenticate from your development machine. Losing control of it can mean losing access to private code, deployment settings, or a trusted public identity.
For job searching, use one account that you can maintain for years. If you already have an account with a suitable username and no content you would not want employers to see, secure and reuse it rather than splitting your work across accounts.
When creating or reviewing the account, make these initial choices:
-
Use a professional, stable username.
A format based on your name is usually best, such asfirstnamelastname,firstname-dev, orfirstname-lastname. Avoid temporary, overly personal, or gaming-style names. -
Use a personal email address you expect to keep.
Do not depend on an employer-provided email address: you may lose access when changing jobs. Verify the email address during signup, and protect that email account with its own multi-factor authentication. -
Create a unique password.
Generate and store a long, random password in a trusted password manager. Do not reuse the password from email, LinkedIn, or another developer service. Password reuse turns one breached service into a risk for all of them. -
Keep private information private.
Your display name, a professional photo, and later a short developer bio can be public. Your password, authentication codes, recovery codes, and authenticator setup QR code must never be public, copied into a repository, sent in chat, or included in a screenshot.
You do not need a polished portfolio profile today. For this lesson, the target is a verified and secure account. Profile positioning and project presentation will come after you have something substantial to show.
Why use an authenticator app instead of SMS?
Multi-factor authentication means that signing in requires more than your password. In this setup, GitHub asks for:
- Something you know: your password.
- Something you have: a temporary code generated by your authenticator app.
The common recommended method is a TOTP app, short for time-based one-time password. After you scan GitHub’s setup QR code, the app generates a new six-digit code at regular intervals. GitHub supports many authenticator apps, so choose one you trust and can access reliably.
A text-message code is better than password-only access, but it is a weaker fallback. SMS messages can be delayed, intercepted, or redirected through a SIM-swap attack. GitHub explicitly recommends a TOTP authenticator app over SMS and suggests security keys rather than SMS as a backup method when possible.
Configuring two-factor authentication - GitHub Docs
Read GitHub Docs’ official setup guidance before changing your account security. It explains the primary TOTP workflow, the limits of SMS, and the optional passkey and hardware-security-key methods.
In “Configuring two-factor authentication using a TOTP app,” follow the TOTP setup in order. Pay particular attention to the QR-code verification and recovery-code download steps. Then read the warning paragraph in “Configuring two-factor authentication using text messages.” Focus on SMS limitations, rather than setting SMS up as your primary method. The “Configuring two-factor authentication using a passkey” and “Configuring two-factor authentication using a security key” subsections are optional for now. Read the passkey option if you use Windows Hello, Touch ID, or Face ID on a personal device. If you own a physical security key, read the security-key role before registering it.
Enable TOTP multi-factor authentication
Open GitHub while signed in, then follow this path:
- Click your profile picture in the upper-right corner.
- Select Settings.
- In the left sidebar under Access, select Password and authentication.
- Find Two-factor authentication and select Enable two-factor authentication.
- Choose the authenticator-app route.
- On your own phone or trusted desktop app, scan the QR code and enter the current six-digit code into GitHub.
- Complete the recovery-code step before confirming that setup is finished.
Treat the QR code and its manual “setup key” as a secret. Anyone who has that information can configure an authenticator that produces valid codes for your account. Do not save it in a plain-text note, send it to anyone for “help,” or take a screenshot of it.
Once setup is complete, the Two-factor methods area should show your authenticator app as enabled. GitHub also allows additional methods such as security keys.

For the immediate job-search portfolio workflow, a good baseline is:
| Account component | Recommended choice | Reason |
|---|---|---|
| Password | Unique password stored in a password manager | Prevents password reuse from compromising GitHub. |
| Primary second factor | TOTP authenticator app | Works without depending on mobile-network delivery. |
| Recovery option | Downloaded recovery codes in a secure password-manager vault | Lets you regain access if your authenticator device is unavailable. |
| Optional additional method | Passkey on a personally controlled device or a physical security key | Reduces dependence on a single device and can make sign-in more resistant to phishing. |
A passkey can be convenient on a personal laptop or phone protected by a device PIN, fingerprint, or face unlock. A physical security key is a separate device that you deliberately connect or tap during sign-in. Neither is required to complete this lesson, and you should not buy hardware simply to proceed. The important requirement is that you have a reliable primary method and safely stored recovery codes.
Recovery codes are your account-access contingency plan
Recovery codes are one-time codes GitHub gives you during 2FA setup. They are for the situation where you know your password but no longer have access to the authenticator app: for example, if your phone is lost, broken, reset, or unavailable while traveling.
The important distinction is this:
- An authenticator code changes regularly and comes from your configured app.
- A recovery code is used only for emergency account access and cannot be reused after use.
Configuring two-factor authentication recovery methods - GitHub Docs
Read GitHub Docs’ recovery-code guidance while you save your own codes. It explains where the codes can be viewed later and what happens when they are regenerated.
In “Downloading your two-factor authentication recovery codes,” read why recovery codes matter. Then follow the navigation steps in that same section: Settings, Password and authentication, then Recovery codes and View. Next, read “Generating a new set of recovery codes,” especially the code lifecycle. Note that a new set invalidates the old one.
Save them in a place that survives loss of your phone
Download the codes, then move them promptly into a secure password manager as a protected note or recovery attachment. Confirm that you could access that password-manager vault from another trusted device if your phone disappeared.
After confirming the secure copy exists:
- Remove the downloaded recovery-code file from your Downloads folder.
- Empty the system trash or recycle bin if appropriate.
- Do not email the file to yourself.
- Do not store it in a GitHub repository, project folder, unencrypted cloud document, or ordinary notes app.
- Do not test a recovery code “just to make sure.” Testing consumes one code.
If you ever use a recovery code or suspect that your codes were exposed, review the remaining codes and generate a new set when appropriate. A newly generated set invalidates every previous recovery code, so replace the stored copy immediately.
Verify the setup without creating a lockout risk
Before considering the task complete, verify the normal sign-in path:
- Keep your current GitHub session open.
- Open a private or incognito browser window.
- Sign in with your GitHub username and password.
- Enter the current TOTP code from your authenticator app.
- Confirm that you reach your account successfully.
- Close the private window; do not use a recovery code for this test.
This confirmation catches common issues, such as scanning the QR code into the wrong app, selecting the wrong account entry, or mistyping a password-manager record.
Record only non-sensitive completion evidence in a personal checklist, for example:
- GitHub email verified
- TOTP authentication enabled and tested
- Recovery codes saved in password manager
- Optional passkey or security key registered, if used
Do not record the actual codes, password, QR code, or setup key in that checklist.
Key takeaways
Your GitHub account will support your job search and portfolio throughout this course, so it must be both professional and secure.
The essential setup is:
- a professional, stable username and verified personal email;
- a unique password stored in a password manager;
- TOTP multi-factor authentication instead of SMS as the primary method;
- recovery codes saved securely and removed from ordinary downloads;
- a normal sign-in test using the authenticator app.
An optional passkey or physical security key can provide another sign-in method, but recovery codes and a working authenticator app are the baseline you need now.
Next, you will define the product brief for an accessible job-application workspace. That brief will guide the portfolio project you will build and publish through this secured GitHub account.
Can't find a good explanation? Sign up and we'll make it for you
Sign up