Start with the facts in front of you
Read the full notice before deciding what it means. A useful new-device alert should give you enough context to answer a few basic questions:
- When did the sign-in happen?
- Which browser and operating system were used?
- What location or internet address was associated with it?
- Does that combination fit something you or a team member just did?
Look at the details together. A city on its own is not proof of anything. Internet providers, mobile networks, travel, and privacy tools can all make a location look imprecise. A browser label can be more helpful when it matches a new laptop, phone, or browser profile you recognize.
Do not forward the alert to the whole team and ask, "Was this anyone?" Start with the people who actually use that account. A smaller check gets you a faster answer and keeps security details from travelling farther than they need to.
Check the ordinary explanations first
An unfamiliar alert does not automatically mean someone has your password.
You may have signed in from:
- A new computer or phone
- A different browser on a familiar computer
- A private browsing window
- A browser profile used only for work
- A device where cookies were recently cleared
- A temporary device while travelling or working from another location
Ask yourself what changed just before the alert arrived. If you replaced a laptop this morning and the notice says Safari on macOS at the right time, the answer is probably simple. If the alert says a browser you do not use at a time when you were with a client, it deserves a quicker response.
If several people work in the practice, use named staff accounts rather than sharing one login. An alert is much easier to investigate when the account belongs to one person and each sign-in has a clear owner.
Verify through a route you trust
If you are uncertain about the email itself, do not rely on its buttons. Open a new browser window and type the practice software address you normally use, or open it from a trusted bookmark.
This separates two questions that can otherwise become tangled:
- Is the sign-in notice genuine?
- Do I recognize the sign-in it describes?
A convincing message can still be a phishing attempt. Check the sender carefully, but remember that a familiar display name is not enough. The safest habit is to reach the account through the route you already know instead of letting an unexpected email choose the route for you.
If the alert is genuine and you recognize the activity, no further action may be needed. Make a quick mental note of what caused it. That will help you interpret a similar notice the next time you change devices or clear browser data.
If it was not you, contain access first
When the sign-in is not yours, stop investigating long enough to secure the account.
Change the password from a device you trust. Choose a password that is unique to this account and save it in a password manager. If the old password was used anywhere else, change it there too, starting with the email account that receives password resets.
Changing a password may not end sessions that are already open. Contact the software provider through its official support route right away and ask them to revoke every other active session. Include the time, device description, and internet address from the alert so support can identify the event without asking you to send passwords or client information.
Then turn on two-factor authentication if it is not already enabled. A second factor gives the account another boundary when a password is exposed. Store recovery codes somewhere your practice can reach during an emergency, but not in the same inbox the account depends on.
Do not create a clever variation of the old password. If PracticeSpring1 may be known, PracticeSpring2 is not a meaningful reset. The new password should have no relationship to the old one.
Protect the email account behind the reset
Your practice email is often the recovery route for every other system you use. If someone can read it, changing one practice-management password may not be enough.
Check the email account for:
- Recent sign-ins you do not recognize
- New forwarding rules
- Recovery addresses or phone numbers you did not add
- Messages moved to trash or marked as read unexpectedly
- Two-factor prompts you did not initiate
Change the email password if anything looks wrong. Review who has access to shared mailboxes and remove old staff promptly. An account can be secure while its recovery inbox remains an open side door.
This is also a good time to stop sharing passwords by email or text. A password manager with controlled sharing gives the practice a cleaner way to grant and remove access without leaving credentials in old conversations.
Look for changes, not just views
After you have changed the password and asked the provider to end other sessions, check the practice account for activity around the sign-in time.
Focus first on actions that could affect clients or money:
- New or changed staff access
- Appointment changes
- Modified contact details
- Exported or downloaded information
- Changed payment, notification, or security settings
- Messages sent from the practice
You may find nothing. That is still useful. Write down what you checked, when you checked it, and what you changed. If you later notice an unexpected action, you will have a reliable starting point instead of trying to reconstruct the day from memory.
If you find suspicious activity or cannot tell what the account did, contact the software provider through its official support route. Share the alert time, device label, internet address, and the steps you have already taken. Do not send client records or passwords in the support message.
Give your team a short response rule
A security alert should not depend on whoever happens to notice it first.
Write a short rule that fits on one page:
- Confirm whether the sign-in belongs to a named person.
- If nobody recognizes it, change the account password from a trusted route.
- Secure the recovery email and turn on two-factor authentication.
- Check important account changes around the alert time.
- Record the response and contact support when needed.
Name who owns each step. In a solo practice, that may all be you. In a larger practice, the person who sees the alert should know who can reset access, who reviews account activity, and who contacts affected people if the review finds a real problem.
Run through the rule once before you need it. You do not have to stage an elaborate exercise. Ask one team member to read a sample alert and explain what they would do. Any hesitation will show you where the instructions need another sentence.
Let expected alerts stay useful
New-device notices lose their value when people learn to ignore them.
If an alert was caused by a new laptop or cleared cookies, say so when a teammate asks. Do not label every notice a false alarm. It was accurate: the account was used from a browser the system did not recognize. Your check established that the activity was expected.
Keep the response calm and brief. The goal is not to make staff anxious about signing in. It is to create a habit where an unexpected signal gets a timely, proportionate check.
The first browser Stillpoint records for an account establishes the starting point and does not produce an alert. After that, Stillpoint emails the staff member when the account signs in from a browser it has not seen before. The notice includes the time, a plain browser and device description, the internet address, and a general location when one is available. It also gives you a direct path to change your password and points you to two-factor authentication. If the sign-in was yours, there is nothing else to do. If it was not, you have a clear place to start.
