Property management account security: who has access?

An employee leaves on Friday. On Monday, their property-management login still works because nobody was sure whether removing it would interrupt rent collection.

As a management company adds staff or changes building assignments, account access needs to follow the work. The fictional departure above calls for a clear operating procedure. Account security depends on knowing who has access and limiting what each person can do. It also needs a tested way to remove or recover access when circumstances change.

Start with named accounts and permissions tied to actual work. Require the strongest authentication your services support, protect recovery channels, and review access whenever staff responsibilities change. A secure login is valuable, but it does not decide whether the person behind it should still be able to view a building or alter a payment setting.

NIST published its updated Digital Identity Guidelines on August 1, 2025, giving this review a timely basis. The guidance addresses identity proofing, authentication, and federation. For a private property operator, it is a technical reference for evaluating controls, not evidence that the business is required to meet every federal assurance requirement. NIST Digital Identity Guidelines.

Inventory accounts by what they can change

Begin with the systems that affect resident information or money. Include the property-management platform, business email, document storage, payment-provider access, and any shared office devices used to reach them.

For each account, record the owner and the business reason it exists. Note whether it can grant access to someone else, change a payout destination, or export sensitive records. Those powers deserve attention even if the account belongs to someone with an ordinary job title.

A small company may discover that the same employee administers the portal and the email address used to recover every other account. If that person loses a phone or isn't available, who can help the rest of the office sign in? Find the answer before staff need it.

Plan for continuity without sharing one person's credentials. Where the service supports it, assign a separate authorized administrator with their own authentication. Document how the company verifies a recovery request and who can approve it. Keep recovery information in an approved secure location, not in a broadly shared spreadsheet.

How should property management staff permissions be assigned?

Consider a hypothetical company managing five buildings. A leasing employee covers two of them. They need applicant and listing access, and may need to read selected lease information. They do not automatically need to change rent-payment settings for all five buildings.

Translate that work into permissions before sending the invitation. Ask which buildings the employee can open, which records they can read, and which actions they can perform. Treat view access and edit access as distinct decisions.

For that fictional leasing role, the company could start its access review with this worksheet. It describes proposed business decisions, not a preset Talvi role or a list of permissions already granted:

Confirm that the actual system can express the intended boundary before relying on it. If a role is broader than the work requires, that difference belongs in the purchasing and access decision, not in a footnote nobody reads.

Test a normal task and an out-of-scope task. The employee should be able to do the assigned work without borrowing an administrator's login. They should also be refused when attempting an action outside their responsibility.

Talvi lets management accounts have different viewing and editing permissions for functions such as payments and documents, with access checked for the relevant building. Try a restricted staff account during a Talvi evaluation. Confirm the actual permissions rather than relying on the title “manager” or “leasing agent.”

Avoid solving every blocked action by expanding a role. First check whether the task belongs to the person, whether their building assignment is correct, and whether the process requires a different approver. A temporary workaround can become permanent access if nobody owns the follow-up.

Understand what multifactor authentication protects

Multifactor authentication asks for more than one category of evidence when a person signs in. The available methods differ in their resistance to an attacker who tricks someone into using a false login page.

NIST's updated authentication guidance states that manually entered one-time passwords are not phishing-resistant and identifies WebAuthn as an example of a phishing-resistant standard. The distinction matters when evaluating a vendor's broad claim that it “supports MFA.” Ask which methods it supports and how account recovery works. NIST authenticator guidance.

Talvi offers authenticator-app codes and text-message verification. These methods don't provide the phishing resistance of passkeys. Evaluate the available methods honestly, and use stronger methods for other business systems where those systems support them.

Teach staff to reach business services through known addresses or saved bookmarks, and to report unexpected authentication requests. No support interaction should require an employee to hand another person a live one-time code. An authentication prompt should make sense in the context of an action the employee initiated.

Protect business email with the same seriousness as the property platform. If it receives reset links or administrative alerts, it is part of the access path. A carefully configured property account can still depend on a poorly managed recovery mailbox.

What should happen when a property management employee leaves?

Make access removal a named responsibility in the staff departure process. Human resources or the owner may decide the timing; a designated administrator should confirm that the change was completed across the relevant services.

The procedure should address active accounts, outstanding invitations, shared devices, and external provider access. Removing someone from one application does not establish that their email or payment-provider account has also been disabled.

Keep operational ownership separate from personal access. Before a planned departure, reassign open work and document the location of business records. Do not preserve an unnecessary login merely because some tasks still display that person's name. Ask the vendor how ownership and historical attribution behave when access is removed.

In the five-building example, the employee's departure should trigger review of both buildings they covered, the shared document folders they used, and any vendor portals where they had accounts. Confirm the result with the account inventory rather than relying on memory.

This illustrative checklist separates unfinished work from a person's ability to sign in. It covers a departing leasing employee assigned to two buildings:

Keep the actual removal timing in the organization's personnel process. The record should show who confirmed each action and when; a checked box without a responsible person is weak evidence. Never put passwords, recovery secrets, or live authentication codes into this handoff.

For an urgent removal, follow the organization's incident or personnel procedure and involve the appropriate responsible people. Preserve relevant business records and audit information. Do not improvise destructive cleanup while trying to cut off access.

Rehearse the lost-phone case

A phone replacement is an ordinary event that can become an improvised security exception. Someone cannot retrieve a code, rent questions are arriving, and a colleague suggests sharing an account until the problem is fixed.

Rehearse recovery before it is urgent. Have the administrator describe the vendor's supported recovery route, the evidence required, and the expected internal approval. Use a test account or a guided exercise where possible so you do not accidentally lock out a live user.

Check whether recovery information is current and who can update it. A former employee's phone number or an abandoned mailbox can remain attached to an account long after daily access appears healthy.

Treat a requested recovery change as a verification task. Use an established contact path and the provider's process. A message that sounds familiar does not by itself establish the requester's identity, especially when it asks to bypass the usual login controls.

After legitimate recovery, review what changed and confirm that the employee can work under their own account. Close any temporary permissions granted during the event. The recovery record should explain the decision without storing secrets or live authentication codes.

Give money-destination changes their own review

Changing where funds are paid is different from editing a resident's phone number. Limit who can initiate that change and decide how another authorized person will verify it when your system and staffing model permit.

Confirm the requested destination through a trusted process. Do not rely solely on contact information included in the request itself. Keep a record of the reason, approval, and provider confirmation according to your financial controls.

Also identify every route through which the destination can change. A control inside your property software may not govern changes made directly in a payment-provider account. Ask the vendor about that boundary and include the provider's access in your review.

This is a useful purchasing test: ask the presenter who can alter a payout destination, what authentication is required, and what happens if the relevant administrator has left the company. A confident description should still be followed by a demonstration or written documentation of the proposed setup.

Keep the review small enough to repeat

An access review doesn't need to become a lengthy annual project. Use the account inventory whenever someone joins, changes responsibility, or leaves. Add a recurring review at a cadence appropriate to your team and risk.

Ask each business owner to confirm that named users still need their assigned buildings and functions. Investigate accounts without a clear owner. Remove access through the supported process and retain the record your organization requires.

Track exceptions with an owner and a review date. A temporary administrator role for a migration is easier to justify when its purpose and end condition are visible. Without those details, a temporary role can outlast the project by years.

Before the firm's next round of hiring, review Talvi's staff permissions and account-recovery workflow. Have the team show a change of building assignment. Write that change into the company's joining and departure checklist, alongside the separate email and payment-provider accounts its administrators control.