Password and Authentication Policy
Most break-ins start with a stolen or guessed password. This policy sets the rules for passwords, multi-factor authentication (MFA), and the other secrets that let people and software sign in.
Document
Policy number
TSS-IT-03
Version
1.0
Effective from
1 September 2026
Next review
March 2027
Owner
IT Team
Approved by
Board of Directors
Applies to
Every employee, trainee and intern with a TSS account, and every system, service account and secret that TSS manages.
Issued by
Thakur Systems & Structures Private Limited, CIN U62011PN2026PTC254650
Related policies
Information Security Policy (TSS-IT-02), Access Control Policy (TSS-IT-11), Software Development and Change Management Policy (TSS-IT-10), Incident Response Policy (TSS-IT-05)
1. MULTI-FACTOR AUTHENTICATION IS REQUIRED
Everywhere it is available. MFA must be switched on for every company account that supports it: workspace and email, code repositories, cloud consoles, the password manager, project tools and client systems.
Best methods first. Use a passkey or hardware security key where possible, then an authenticator app. Use SMS codes only where nothing else is available.
Unexpected prompts. Never approve an MFA prompt you did not start. If you get prompts you did not expect, deny them and tell the IT team immediately, because it means someone has your password.
Never share codes. Do not share MFA codes with anyone, including someone who says they are from IT. The IT team will never ask you for them.
Backup. Register a backup method, and keep your backup codes in the password manager.
2. PASSWORDS
Length. At least 12 characters. A passphrase of four or more random words, such as “tractor monsoon violet ladder”, is stronger and easier to remember than a short, complicated password. (Do not use that example.)
Unique. Use a different password for every account. Never reuse a company password anywhere else, and never use a personal password for a company account.
Hard to guess. Avoid names, birthdays, phone numbers, the company or client name, keyboard patterns, and common words with a number added at the end.
No scheduled changes. We do not make you change passwords on a timetable, because that tends to produce weaker passwords. Change a password immediately if you think it may have been seen, guessed or leaked, or if the IT team asks you to.
Leak checks. Where our tools support it, new passwords are checked against lists of known leaked passwords.
3. PASSWORD MANAGER
Use the company-approved password manager to create and store all work passwords. Its master password must be a strong passphrase that you use nowhere else, protected by MFA.
Do not store work passwords in your browser, a notes app, documents, spreadsheets, sticky notes or chat messages.
Where a shared login cannot be avoided, such as a client’s shared test account, it is kept in a shared vault that the IT team controls, and never passed around in chat.
4. DEVICES
Laptops. Sign in with a password or PIN, plus fingerprint or face recognition where available. The screen locks automatically after five minutes.
Phones used for sign-in codes. Protect them with a PIN of at least six digits, or with fingerprint or face recognition.
5. FAILED SIGN-INS
Accounts lock after ten failed sign-in attempts in a row, and unlock after a waiting period or when the IT team unlocks them.
6. SECRETS USED BY SOFTWARE
What counts. API keys, tokens, database passwords, certificates and SSH keys are all secrets.
Where they go. Store them only in the approved secrets manager, or in the secret storage of our build and deployment system.
Where they never go. Source code, configuration files committed to Git, screenshots, tickets, logs, or prompts to AI tools.
If one leaks. Secret scanning is switched on in our code repositories. If a secret is ever committed, even for a moment, treat it as leaked: tell the IT team and replace it immediately. Deleting it in a later commit is not enough, because it stays in the history.
SSH keys. One key per person, protected with a passphrase, and removed when access ends.
Service accounts. Software uses its own service accounts, never a person’s account. Service accounts are reviewed every three months.
7. LEAVERS AND ROLE CHANGES
When someone leaves or changes role, the IT team removes their access the same day, and changes any shared secrets they knew.
8. PASSWORD RESETS
The IT team resets a password only after checking who you are, for example on a video call or in person, and never on the strength of an email or message alone.
9. BREACHES
Sharing passwords or MFA codes, or deliberately weakening sign-in security, is a serious breach of this policy.