Yardi User Security: Roles, Permissions, and Access Reviews That Hold Up
Use this guide to design role-based Yardi user security, scope permissions and menu sets to real job functions, separate duties in financial workflows, and run a repeatable user access review your auditors will actually accept.
15 min read
Includes access review checklist
Updated August 2026
Yardi user security is the combination of user accounts, roles, permissions, menu configuration, and property-level access that controls what each person in your organization can see and do inside Yardi. When it is structured well, it protects financial and resident data, keeps approvals accountable, and makes audits faster instead of harder.
Most access problems are not caused by missing platform capability. They accumulate through turnover, acquisitions, temporary workarounds, and role changes that nobody circles back to clean up. The stakes are real: the Association of Certified Fraud Examiners' Occupational Fraud 2024 report found a median loss of $145,000 per fraud case, rising to $200,000 in real estate, and tied more than half of all cases to either a lack of internal controls (32%) or an override of existing controls (19%).
Yardi user security spans five layers: user accounts, roles and permission groups, function permissions, menu configuration, and property or entity-level access.
Design roles around job functions, not individuals. Person-specific permission grants are the access rights reviews most often miss.
Segregation of duties lives in two places: role permissions and workflow approval routing. Both need to agree.
Run a quarterly user access review with a named owner, a documented scope, and a written outcome. Drift returns quickly without a cadence.
Offboarding is a same-day security task, not a monthly cleanup item.
Chapter 1
What Yardi User Security Covers
Yardi user security is the access-control model inside a Yardi environment: user accounts, roles or security groups, function-level permissions, menu configuration, and property or entity-level visibility. Together these layers determine what each user can view, enter, change, approve, export, and report on.
Each layer answers a different question, and most real-world problems come from treating them as one setting. An account controls whether someone can log in at all. A role bundles permissions so access can be granted consistently. Function permissions decide what actions are allowed. Menu configuration shapes what a user sees day to day. Property and entity scoping decides which portfolios that access applies to.
Layer
What it controls
Most common gap
User accounts
Who can sign in; MFA and password policy
Inactive and former-employee accounts left enabled
Roles / security groups
Reusable permission bundles by job function
Roles copied from a power user, then never trimmed
Function permissions
What a user can enter, edit, post, approve, export
One-off grants outside any role, invisible to reviews
Menu configuration
Which screens, reports, and tools a user sees
Everyone sees everything, so training and errors multiply
Property / entity access
Which portfolios, entities, and books access applies to
Regional staff who can see every property in the database
The permission model in Yardi Voyager is granular by design, spanning thousands of individual functions across accounting, leasing, procurement, maintenance, reporting, and administration. That granularity is an asset for a well-run organization and a liability for one that assigns access ad hoc. The rest of this guide is about staying on the right side of that line.
Chapter 2
How Access Drift Happens
Access drift is the gradual gap between what users can do in Yardi and what their current jobs require. It builds through turnover, promotions, acquisitions, temporary workarounds, and copied user profiles, and it usually stays invisible until an audit, an error, or an incident exposes it.
No one designs a bad security model on purpose. The environment that fails an access review almost always started with a reasonable setup that aged without maintenance. The mechanics are predictable:
A new hire is set up by copying the profile of the most capable person on the team, inheriting years of accumulated rights.
An employee changes departments and gains the new role's access without losing the old one.
A vacation coverage exception gets granted in an afternoon and revoked never.
An acquisition brings a second user population with a different permission philosophy, and go-live pressure defers the reconciliation.
A departure is processed in payroll and email on day one, and in Yardi at month three.
The cost of letting this ride is not hypothetical. The ACFE's 2024 study estimates organizations lose about 5% of revenue to fraud each year, and the median scheme runs 12 months before detection. On the data side, IBM's 2024 Cost of a Data Breach report put the global average breach cost at $4.88 million, and Verizon's 2024 Data Breach Investigations Report found 68% of breaches involved a human element such as error or misused access. Property management sits on exactly the data attackers and dishonest insiders want: bank accounts, owner distributions, vendor payment details, and resident personal information.
Quick self-test: pull your active user list and count the accounts belonging to people who no longer work for you, plus users whose roles changed in the last year without an access review. If either number is above zero, drift is already priced into your environment.
Chapter 3
Design Roles Around Jobs, Not People
Role-based access control in Yardi means defining a permission set per job function, assigning users to roles, and treating individual permission grants as documented exceptions. It makes onboarding consistent, reviews faster, and departures a group-membership change instead of a forensic exercise.
Role-based access control is a security model that grants permissions to job functions rather than named individuals. Start by listing the actual jobs in your operation: leasing agent, property manager, regional manager, AP clerk, senior accountant, controller, system administrator. For each, define what the job needs to enter, approve, view, and report on. That list becomes the role definition, and least privilege becomes practical instead of aspirational.
Dimension
Person-based grants
Role-based model
New hire setup
Copy someone's profile, inherit their history
Assign the role for the job, done
Role change
Old rights linger alongside new ones
Swap role membership, old access ends
Access review
Audit every user line by line
Audit the role once, then check membership
Accountability
Nobody knows why a grant exists
Every grant traces to a documented role
Scale
Breaks past a few dozen users
Holds up through growth and acquisitions
Two design cautions from the field. First, resist creating a role per person; if you have 80 users and 74 roles, you have person-based access with extra steps. Most operations run well on 8 to 15 roles plus a small set of documented exceptions. Second, keep administrative rights rare. Full system administration belongs to a small named group, and day-to-day power users can get targeted elevated functions without the keys to the security model itself.
Chapter 4
Scoping Permissions and Menu Sets
Permission scoping decides what a role can do; menu configuration decides what its users see. Trimming menus to each role's actual work reduces training time, misposts, and accidental exposure, and it makes the environment feel simpler without removing any capability the job needs.
Permissions and menus fail differently. An over-permissioned role is a control problem: someone can post, approve, or export beyond their responsibility. An over-cluttered menu is an operations problem: users hunt through screens they never use, call the help desk more, and occasionally open the wrong one. Both get fixed in the same design pass.
Work function by function, not screen by screen. For each role, walk its real weekly workflow and confirm three things: the functions the role uses are granted, the functions it never uses are removed, and the sensitive functions (posting to the GL, changing vendor banking details, editing security settings, exporting full resident lists) are limited to roles with a stated business reason. Export rights deserve particular attention because they move data outside every control you have configured inside Yardi.
Menu configuration then makes the granted set visible and nothing else. A leasing role that sees leasing, resident, and reporting menus, without AP or GL screens, onboards faster and generates fewer mistakes. Teams that invest here typically see the payoff in support volume first; it is one of the quiet wins we see in ongoing Yardi support engagements, where cleaner menus reduce recurring "where do I find this" and "I posted this in the wrong place" tickets.
Chapter 5
Property, Entity, and Sensitive-Data Visibility
Property-level security limits each user's access to the portfolios and entities they actually manage. It is one of the most effective and least used controls in Yardi environments, because many organizations need identical permissions across teams while needing very different property visibility.
Ask two separate questions about every role: what can it do, and where can it do it. A property manager in one region and a property manager in another region usually need the same functional permissions with entirely different property scopes. Scoping by property or entity keeps mistakes local, keeps regional reporting honest, and matters even more in fee-managed portfolios where different owners' data lives in one database.
Sensitive-data visibility is the second half of this chapter. Confirm, deliberately, who can see bank account numbers, social security numbers, owner distributions, payroll-adjacent records, and vendor payment details. Visibility in Yardi often grows through inheritance rather than decisions; a report grants a column, a role copies a role, and two years later the leasing team can technically open ownership statements. Nobody chose that outcome, and an access review is usually the first time anyone notices it.
This is also where multi-entity growth gets risky. In our engagement with White Mountain LLC, user security groups and core access rules were part of the go-live foundation precisely because wave-two portfolio expansion was already planned; scoping done at implementation is far cheaper than scoping retrofitted after growth.
Chapter 6
Segregation of Duties in Financial Workflows
Segregation of duties is an internal control that splits a financial process across multiple people so no single user can create, approve, and pay a transaction alone. In Yardi it is enforced twice: in role permissions and in workflow approval routing. Both must agree, and both must survive staffing changes.
The classic failure pattern in property management is the trusted long-tenured employee who can set up a vendor, enter its invoices, approve them, and initiate payment. The ACFE's 2024 data shows why this deserves attention: billing schemes appear in roughly a fifth of occupational fraud cases, and frauds at organizations lacking basic controls last significantly longer and cost more. Small and mid-sized operators are hit disproportionately because one person wearing four hats is normal there.
Map your money-movement processes and split the incompatible steps:
Vendor creation and vendor payment should not sit with the same role.
Invoice entry and invoice approval should be separated, with approval thresholds that escalate by amount.
Bank account changes (for vendors or owners) should require a second person's confirmation.
Journal entry posting and account reconciliation should not be the same person for the same accounts.
Security administration itself should be separated from financial processing; the person who assigns permissions should not also process payments.
Role permissions set the boundaries, and approval workflows enforce the sequence. The two drift apart when staffing changes, which is why our guide to Yardi workflow approvals through vacations, role changes, and departures pairs with this one: role-based routing, backup approvers, and escalation rules are segregation of duties expressed in workflow form. Where a full split is impossible in a small team, compensating controls (a second reviewer on the bank rec, an owner-level review of vendor changes) close most of the gap.
Chapter 7
Audit Trails: The Evidence Your Reviewers Will Ask For
An audit trail records who did what, and when, inside the system: logins, record changes, postings, approvals, and security changes. Yardi captures this history, but it only becomes a control when access is limited enough for the trail to mean something and someone actually reviews it.
Audit trails serve three audiences. Operationally, they answer "who changed this lease charge" in minutes instead of a meeting. For financial audits and lender or insurance reviews, they provide the documented evidence that controls exist and operate; reviewers increasingly ask for user lists, permission reports, and change history rather than verbal assurances. And in an incident, they are the difference between reconstructing events and guessing.
Two practices make the trail worth having. First, keep shared logins at zero. A generic "frontdesk" account turns every logged action into an anonymous one and quietly voids the control. Second, put the high-risk trails on a review cadence: security and permission changes, vendor banking changes, and posting-period overrides deserve a periodic look by someone other than the person who makes them. A trail nobody reads is storage, not a control.
Chapter 8
The Quarterly User Access Review
A user access review is a scheduled check that every account, role assignment, and permission still matches current jobs. Quarterly is the standard cadence: frequent enough to catch drift before it compounds, light enough that managers actually complete it. Each review needs an owner, a scope, and a written outcome.
This is the control that keeps every other chapter true. Without a cadence, role design decays back toward drift within a year or two of turnover. With one, the review shrinks over time because each pass leaves the environment cleaner than the last. The first review is the heavy one; teams commonly deactivate a meaningful share of their user list on the first pass, and each subsequent quarter gets faster.
Review item
Cadence
Who confirms
Active user list vs. current staff roster
Quarterly
System admin with HR list
Role membership per department
Quarterly
Department managers
Documented permission exceptions
Quarterly
System admin; expire or renew each one
Admin and elevated-rights accounts
Quarterly
Leadership sign-off
Sensitive-data visibility and export rights
Semiannually
Controller or compliance owner
Approval routing vs. current org chart
Semiannually
Controller and department heads
Full security model re-baseline
After major change
Implementation or acquisition team
The review checklist
Export the active user list and reconcile it against the current employee and vendor roster.
Deactivate departed users, stale service accounts, and any shared logins.
Have each manager confirm their team's role assignments in writing.
List every permission granted outside a role; renew with a reason or remove.
Verify admin rights are limited to the named administrator group.
Spot-check who can view bank details, SSNs, and owner reporting.
Confirm approval workflows route to current roles, with backups and escalation set.
Record findings, actions taken, and sign-off; file it where your auditors can find it.
The written record matters as much as the cleanup. A dated review document with findings and sign-off is exactly the artifact financial auditors, lenders, and cyber insurers ask for, and producing it from a standing process costs a fraction of reconstructing it under deadline.
Chapter 9
Onboarding, Role Changes, and Offboarding
The user lifecycle is where security models are won or lost. Onboarding should grant a role, not copy a person. Role changes should remove old access the day new access is granted. Offboarding should deactivate the account within one business day, with pending approvals rerouted first.
If chapters 3 through 8 describe the structure, this chapter describes the habits that keep it standing. Three moments matter:
Onboarding
Assign the documented role for the job. If the role does not fit, fix the role definition rather than adding one-off grants. Enable MFA and account basics before first login, a point our earlier post on secure user setup fundamentals covers in more depth.
Role change
Treat an internal move as an offboard-plus-onboard: remove the old role the same day the new one is granted. Accumulated dual access from promotions is one of the most common findings in access reviews.
Offboarding
Deactivate within one business day. Reroute the person's pending approvals and workflow queue first so invoices and requests do not strand, then remove them from security groups and routing rules.
Vendors and temporary access
Give consultants, auditors, and integration accounts an expiration date at creation. Temporary access without an end date is permanent access with better branding.
Operators rarely lack the intent here; they lack the trigger. Wire the Yardi step into the HR checklist for hires, transfers, and departures so system access changes on the same day employment status does. Portfolio-wide cleanups are also a natural moment to reset the lifecycle habits: role and user security cleanup was a core workstream in our engagements with Bedrock Communities and Woodfield Development, in both cases alongside broader workflow and reporting work rather than as an isolated IT task.
Chapter 10
When Outside Help Makes Sense
Outside help is worth considering when nobody owns the security model, when an audit or insurance renewal needs documented access controls, after acquisitions or implementations, or when the cleanup is too large to fit around daily operations. The work is a structured review, a redesign, and a maintainable cadence.
Plenty of teams can run this playbook internally, and this guide is written so they can. The good-fit signals for bringing in help are practical: the user list has never been reconciled, permissions predate everyone currently on staff, an auditor or insurer has started asking for access documentation, or leadership simply wants an independent read on how far the environment has drifted before deciding what to fix.
BC Solutions approaches this as consulting work rather than an IT ticket queue: a structured review of users, roles, permissions, visibility, and approval routing; a redesign that matches how the organization actually operates; and a handoff that leaves your team with documentation and a review cadence you can run without us. The review side of that work is described in more detail in our overview of the Yardi security audit, and many clients maintain the cadence afterward through Concierge Club ongoing support.
Frequently Asked Questions
How do you delegate roles and permissions to staff in property management software?
Define roles around job functions rather than individuals, assign each role a documented permission set based on least privilege, and add or remove staff from roles as responsibilities change. Person-specific permission grants should be rare, documented exceptions, because they are the access rights reviews most often miss.
What should a Yardi security audit review?
A Yardi security audit should inventory active and inactive users, review how roles and permission groups are assigned, confirm who can see sensitive financial and resident data, test approval and workflow controls, and produce a prioritized remediation plan with documentation leadership can act on.
How often should you review Yardi user access?
Review active user lists and role membership quarterly, review sensitive-data visibility and approval routing semiannually, and re-baseline the full security model after implementations, acquisitions, reorganizations, or leadership changes. Offboarding checks should run within one business day of any departure, not on the review calendar.
What is segregation of duties in property management?
Segregation of duties is an internal control that splits the steps of a financial process, such as vendor setup, invoice entry, approval, and payment, across different people so no single user can complete the process alone. In Yardi environments it is enforced through role permissions and workflow approval routing.
Does Yardi support role-based access control?
Yes. Yardi Voyager supports grouping permissions into roles or security groups and assigning users to those groups, along with menu configuration and property-level access controls. Most access problems come from how organizations use those tools over time, not from missing capability in the platform.
Want an independent read on your Yardi user security?
BC Solutions helps operators review user access, redesign roles and permissions, separate duties in financial workflows, and stand up an access review cadence your team can maintain.
