Changing every password every month can feel like a visible sign of good security. Unfortunately, a calendar does not tell you whether a secret is exposed, whether somebody still has permission to use it or whether the replacement is any better. A useful password policy links changes to risk and maintains the whole account, rather than measuring success only by the number of resets performed.
This guide explains when a change is justified, how to carry it out properly and why reviewing access regularly is different from rotating every password blindly. Workplace and privileged accounts may have additional requirements, so do not treat personal-account advice as permission to disregard an organisation's policy.
Change for a reason, not just a date
For an ordinary account, prioritise replacement after suspected compromise, known exposure, reuse or a change in who is authorised to know the secret. Keep independent passwords and protected recovery methods in place between those events. Review account ownership, sessions and permissions periodically, even when no password change is necessary.
The distinction matters: a password can be old without being exposed, and it can become exposed minutes after creation. Age alone is not a complete assessment of its confidentiality.
Why routine expiry is no longer a universal rule
The NIST guidance rejects arbitrary periodic password changes within its framework while requiring action when compromise is indicated. The CNIL recommendation also distinguishes ordinary users from privileged accounts. These are context-specific recommendations, not a claim that no password should ever be renewed.
One practical problem with forced expiry is the replacement recipe it encourages. A user may keep a familiar base and increment a number, add a season or move a symbol. The form records a change, but the underlying choices remain linked. Repeated expiry can also lead to temporary notes and confusion about which version works.
The useful alternative is not inactivity. It is stronger initial selection, independence between accounts, additional authentication where available and a clear response when confidentiality becomes uncertain.
Recognise events that justify renewal
Replace a value if you entered it on a phishing page, if password-related data from the service may have exposed it or if it circulated in a readable document outside its intended audience. If somebody gains access to a shared secret and then loses authorisation, consider how that secret must be replaced on the external service.
Reuse is another reason. Even without an incident, move away from a password that opens several independent accounts. Do not wait for one website to disclose it. If exposure is confirmed, replace every reused version, prioritising accounts that recover or administer others.
An unsuccessful login attempt has a different meaning from a successful unauthorised login. Investigate the account's events rather than assuming any warning proves the password is known. If you change it as a precaution, still review sessions, recovery contacts and connected applications. A reset should not hide unfinished investigation.
Our compromise-checking guide helps interpret these signals, while the account recovery guide covers confirmed misuse.
Review access without renewing everything
A periodic review asks whether the account still has the right owner, whether recovery contacts remain accessible and whether authorised devices are recognised. Check that application permissions remain necessary. These questions produce useful actions even if the password stays unchanged.
For example, you might discover an unused account that can be closed after preserving necessary records. Or you may find an old integration with broad access. Changing the account password without dealing with either issue does not address the same problem. Use each review to reduce unnecessary access and clarify ownership.
Keep a simple record of review dates and decisions, not a parallel list of passwords. For personal use, a short account checklist can be enough. For a team, assign owners and agree who is responsible for follow-up. A review nobody owns is unlikely to resolve the findings it creates.
Create a replacement unrelated to the old value
When a change is necessary, generate a new independent value. Do not start from the old password and add another exclamation mark. If an attacker knows the previous value, your replacement should not depend on a recognisable transformation of it.
Open the official service, use its password-change flow and save the value only after the change is confirmed. Perform a login check where practical. If you pause halfway, note the operation's status without recording the secret in your action log. Separate a proposed change, a confirmed change and a successful login.
Update the correct vault entry. Similar names can represent distinct customer and administrator accounts, while different domains can point to one account. Confirm the username and the purpose before deleting old records. Remove temporary readable copies created during the operation, while recognising that deletion alone cannot revoke copies already obtained elsewhere.
Treat employee departures as access changes
For a named user, disable or remove the user's access in the external service according to the organisation's process. Changing colleagues' passwords without removing the departing person's own account misses the main point. Check group membership and related permissions too.
For a common account whose secret the person knew, renewal may be necessary because removing a shared-vault entry cannot make the person forget the value. Give the replacement only to people still authorised and inspect the service's session controls. A change in a manager does not automatically revoke external access.
Use the departure as an opportunity to replace unnecessary shared accounts with named users when the provider supports them. Document remaining common accounts, their owner and why they are needed. Our secure sharing guide explains how to plan this before a mission begins.
Coordinate changes that affect several people
Identify how the credential is used before changing it. A shared login might also be configured in an application or device. Renewing it immediately before an important operation without checking dependencies can cause avoidable disruption and encourage people to restore the old arrangement.
Assign a responsible person and a suitable time. Prepare the distribution to remaining authorised users and a check that each necessary workflow still functions. Avoid emailing the replacement to everybody who ever received the original. The intended audience should follow current access needs, not the old contact list.
Technical secrets may require a procedure different from an ordinary website password. Configurations can need updates in a particular order, and service keys may have separate lifecycle controls. Ask the relevant administrator instead of assuming the account's reset button changes every associated credential.
Soclyde Premium can help organise and share access through an encrypted device-held vault. The actual password renewal and removal of rights still take place in the external service. Do not confuse a convenient record of access with an automatic revocation mechanism.
Handle existing workplace requirements constructively
An organisation may still impose expiry for sector-specific requirements, particular systems or privileged access. Follow the applicable policy while raising predictable substitutions and operational problems with the responsible team. An individual user does not have enough context to silently replace the organisation's security requirements.
A useful discussion asks what risk the rule addresses and what safeguards accompany it. Can the service check exposed values? Are independent secrets, recovery controls and additional authentication in place? Are administrator and ordinary accounts treated differently? Avoid reducing the debate to a choice between changing everything frequently and doing nothing.
If a calendar-based requirement remains, generate independent replacements and use a manager to keep them current. Complying with the schedule does not require carrying the same root through each generation.
Measure outcomes rather than reset totals
Look for fewer reused passwords, clearer owners, fewer unnecessary shared accounts and recovery details that have actually been checked. A completed departure procedure is more meaningful than repeated changes to a secret while former users keep their permissions.
Track the reason for each important renewal and whether the resulting login was verified. That record helps during an incident without exposing the secret itself. It also reveals repeated operational failures, such as people storing emergency copies because the approved method is too difficult to use.
Regularly improve the workflow. If changes trigger confusion, investigate storage, permissions and instructions rather than responding with even more frequent expiry. A policy should make secure behaviour practical and explain what to do when an exposure occurs.
Run a short review that leads to decisions
A practical review session can focus on a small group of accounts rather than all your services at once. Choose the mailbox and the accounts it recovers, or choose the tools used by a particular project. Confirm the owner, current recovery details and who remains authorised. Mark unresolved questions instead of changing secrets merely to make the checklist look complete.
If a common account has no known owner, assign responsibility before the next departure or incident. If recovery points to a person who no longer works with you, correct that dependency through the provider's process. If a password is independent and no exposure is indicated, record the review without inventing a need for renewal.
Set a follow-up for findings you cannot finish immediately, such as a supplier integration requiring administrator input. The outcome should be concrete decisions, named responsibilities and completed checks. A large document with no action owner offers little help when access needs to change quickly.
This also keeps reviews proportionate. Personal accounts may require only a few notes; business administration needs a clearer handover record. In both cases, track the decisions while leaving the secrets in their protected storage location.
Maintain accounts and change secrets deliberately
Review access regularly, but renew passwords for a justified reason and with a complete procedure. Use independent replacements, verify account recovery and handle shared-access departures in the service itself. Continue with the complete password security guide to build an approach that protects accounts throughout their life rather than only at scheduled reset dates.