In the previous article in this series, we looked at how HR data moves through three distinct states — at rest, in transit, and in use — and why each state requires its own protective measures. Data in use, we noted, is the state where encryption provides the least direct protection, because by definition the data needs to be readable to be useful. The person or system accessing it has been granted permission to see it. The critical questions become: was that permission appropriate, is it properly scoped, and is what happens during that access controlled and traceable?
Those questions sit at the heart of access control — not as a feature, but as an ongoing discipline.
There is a statistic that should concern anyone responsible for employee data: weak or stolen passwords are involved in the majority of corporate data breaches. Not sophisticated zero-day exploits. Not nation-state attackers. Passwords.
Passwords are the oldest and most widely understood form of digital security, which also makes them the most widely attacked. They can be guessed through automated tools that try millions of combinations per second. They can be stolen through phishing. They are frequently reused across personal and professional accounts, meaning a breach of an unrelated service exposes credentials that also unlock business systems. And they are shared — between colleagues covering for each other, between managers and assistants, between HR staff who find it faster to use a common login than to request individual access.
For HR systems specifically, this matters more than it does for almost any other enterprise application. The data behind that login screen is not a project management tool or a marketing calendar. It is every employee’s personal and financial life, concentrated in one place, accessible to whoever can authenticate.
Access control is the discipline of managing who gets in, what they can do once they are inside, and what happens when something goes wrong. It is also one of the areas where there is the greatest distance between what organizations assume is in place and what is actually configured.
This article covers how access control works in modern HR systems, why each layer exists, and what questions to ask to understand whether your current setup is genuinely protective or merely adequate on paper.
Authentication: proving you are who you say you are
Authentication is the process of verifying identity before granting access. In an HR system context, it answers the question: is this person actually authorized to be here?
A username and password is authentication at its most basic. It persists because it is familiar and requires no additional infrastructure. But it has a fundamental weakness: a password is a secret that can be transferred. The moment a password is phished, guessed, or shared, the system cannot distinguish between the authorized user and the attacker. Both present the same credential. Both receive the same access.
A username and password is authentication at its most basic. It persists because it is familiar and requires no additional infrastructure. But it has a fundamental weakness: a password is a secret that can be transferred. The moment a password is phished, guessed, or shared, the system cannot distinguish between the authorized user and the attacker. Both present the same credential. Both receive the same access.
Password standards matter more than most organizations realize
Not all password policies are equal. A system that allows six-character passwords without complexity requirements is a lot less secure than one that enforces twelve characters with a combination of uppercase, lowercase, numbers, and special characters. A system that never forces password rotation accumulates risk over time: a credential compromised months ago may still be valid today without anyone knowing.
But password complexity alone does not solve the problem. The most common response to strict password requirements is predictable human behavior: people write passwords down, store them in unprotected files, or cycle through minor variations of the same base password. Policy strength and actual security are not the same thing.
Hashing is the mechanism that protects stored passwords from being useful even if a database is breached. Rather than storing the password itself, a well-designed system stores a mathematical transformation of the password — a hash — that cannot be reversed to reveal the original. When a user logs in, the system hashes what they enter and compares it to the stored hash. The actual password never needs to be stored or transmitted.
Not all hashing is equivalent. A system using a unique obfuscation key per user (commonly known as a salt), meaning the same password produces a different hash for each person, provides meaningfully stronger protection than a system using no salt or a single shared salt.
If a database containing hashed passwords is stolen, unique per-user keys prevent attackers from using precomputed hash tables to reverse-engineer credentials at scale.
| The practical question this raises for any organization: if your HR system, or any connected system, were breached tomorrow, would the passwords stored in it be usable by an attacker? If the answer is unclear, it is worth asking your vendor directly. |
Multi-factor authentication: making stolen credentials insufficient
Multi-factor authentication (short MFA) addresses the core weakness of passwords by requiring a second form of verification that cannot be stolen the same way. Even if an attacker has obtained a valid username and password, they cannot access the system without the additional factor.
The most common implementations in HR systems are:
A time-based code generated by an authenticator application on the user’s registered device. The code changes every thirty seconds and is useless after it expires. An attacker who has stolen credentials would also need physical access to the device.
An email or SMS verification sent to a registered address or phone number at login. This is less secure than an authenticator app (phone numbers can be ported, and email accounts can be compromised) but it is substantially better than no second factor.
A biometric confirmation on a mobile device, using fingerprint or facial recognition. This is increasingly standard on mobile applications and provides strong authentication without requiring users to manage additional codes.
A PIN token, a fixed numeric code associated with a specific user, used as a secondary verification for specific high-risk actions within the system rather than at login.
| The practical implication of MFA is significant. Organizations that have implemented MFA consistently report dramatic reductions in account compromise incidents. Not because the underlying credentials become stronger, but because a stolen credential alone stops being sufficient. An attacker who has phished an HR manager’s password still cannot access the system without a code that expires in thirty seconds and exists only on a device the HR manager is holding. |
For systems holding this category of data, MFA represents a meaningful step up from password-only authentication. The data involved — payroll records, identity documents, bank account details — justifies the minor additional friction of a second authentication step.
MFA strengthens the authentication moment itself. A related but distinct question is how authentication is managed consistently across all the systems an employee accesses — which is where Single Sign-On becomes relevant.
Single Sign-On: centralized access, centralized control
Single Sign-On is not about making any individual authentication stronger. It is about centralising how authentication is governed across systems — and what that centralisation makes possible.
Single Sign-On (short SSO) allows a user to authenticate once and access multiple systems without re-entering credentials for each one. The user logs into the organization’s identity provider, for example Microsoft Azure AD, Google Workspace, ADFS, or a similar platform, and that authenticated session is recognized across all connected applications, including the HRIS.
The security benefit is less obvious than it appears. SSO does not inherently make authentication stronger — it centralizes it. The value comes from what centralization enables.
When an employee leaves the organization, IT deactivates their account in the identity provider. That single action revokes access to every connected system simultaneously: the HRIS, email, payroll, benefits platforms, project management tools. Without SSO, offboarding requires IT to manually deactivate accounts across each individual system. In practice, some accounts are missed. A former employee whose HRIS access was not revoked retains the ability to access employee data after their departure. This is one of the most common sources of insider incidents — not malicious actors, but overlooked accounts.
SSO implementations using SAML 2.0 or OAuth 2.0 protocols connect the HRIS to enterprise identity infrastructure that IT already manages and monitors. This means access control for HR data operates within the same governance framework as the rest of the organization’s systems, rather than as a separate silo that HR manages independently.
| One nuance worth noting: Generic consumer SSO, like using a personal Google or Facebook account to authenticate, does not provide the same security model. Consumer accounts are not under the organization’s control, are often shared across personal and professional contexts, and cannot be centrally revoked when an employee leaves. Enterprise SSO through a managed identity provider is a different proposition. |
Authorization: controlling what authenticated users can actually do
Authorization operates within the “data in use” state described in the previous article. It answers the question: “given who you are, what are you allowed to do”. It determines what happens once data is accessible.
These are distinct problems that require distinct solutions. A system with strong authentication but weak authorization is one where any authenticated user can access anything — which, for an HR system containing everyone’s salary, performance history, and personal details, is not much better than having no security at all.
Role-based access control
Role-based access control (short RBAC) is the standard framework for authorization in HR systems. Users are assigned to roles, and roles define permissions. For example:
- The payroll team can run payroll and access compensation data.
- Recruiters can access candidate records and manage job postings.
- Line managers can view and approve requests from their own team but not from other departments.
- HR administrators can configure the system but may not necessarily have access to the underlying employee data that the configuration governs.
The principle underlying RBAC is called least privilege: every user should have access to exactly what their role requires, and nothing more. This is not about distrust, it is about limiting the blast radius if an account is compromised. If an attacker gains access to a recruiter’s credentials, least privilege ensures they can see candidate information but cannot access payroll data or change employment terms.
In practice, RBAC requires four dimensions of control that a serious HR system should support:
These four dimensions together create a permission model that is specific enough to be meaningful. A system that only controls which modules users can access, but not what data they see within those modules, provides significantly weaker protection than one that operates at all four levels.
The access creep problem
Access permissions in HR systems tend to accumulate over time in ways that erode the principle of least privilege without anyone making a conscious decision to change it. Here are three examples of how this can happen in practice:
None of these situations typically involve harmful intent. They are the natural result of systems that are configured once and rarely reviewed. The consequence is that the actual permission state of the system diverges progressively from the intended permission state, and that divergence is invisible until something goes wrong.
Regular access reviews, structured processes where managers confirm that their team members’ permissions remain appropriate, are the standard countermeasure.
| In a well-governed HR system, access reviews happen at least annually, and ideally more frequently for high-privilege roles. The records of those reviews are themselves logged, providing evidence of active oversight rather than passive assumption. |
The offboarding gap: access control’s most consistent failure point
If access management has a single highest-risk moment, it is when an employee leaves the organization.
| In practice, the timing of access revocation varies significantly across organizations. Some revoke access at the moment an employee clears security on their last day. Others process it through an HR-IT workflow that takes days. Some discover months later that accounts were never properly closed. |
The risks during that window are not theoretical. A departing employee who retains payroll access for a week after their final day has had a week of opportunity. A former manager whose account was deactivated but whose credentials were cached in a personal device may retain access beyond what anyone intended.
Effective offboarding from an access control perspective requires three things:
- a defined trigger point at which access revocation begins,
- a structured checklist that covers all systems — not just the primary HRIS, but every integrated application, and
- a verification step that confirms revocation has actually occurred rather than assuming it has.
SSO, as noted earlier, simplifies this significantly. A single identity provider deactivation cascades to all connected systems. But it only works if all systems are connected to the identity provider, which is not always the case for older integrations or legacy modules.
What good access control looks like in practice
The difference between an organization with strong access control and one with adequate-on-paper access control is usually visible in four areas:
Specificity of configuration.
A system where access is defined at the function, data, action, and workflow level is more protective than one where access is controlled only by module. The question to ask your vendor is not whether RBAC exists, but how granularly it can be configured.
Regularity of review.
Access permissions that are set during implementation and never revisited will diverge from reality over time. Organizations with strong access governance schedule formal reviews, log the outcomes, and act on what they find.
Quality of audit trails.
Every access event: successful logins, failed attempts, data queries, exports, permission changes should be logged with enough detail to reconstruct what happened. Logs that are deleted after thirty days are less useful than those retained for ninety. Logs that only IT can access are less useful than those that HR leadership can also review.
Active monitoring.
Audit logs answer the question of what happened. Active monitoring addresses a different question: what is happening right now that looks unusual? A well-configured HR system should be capable of flagging patterns that warrant attention (multiple failed login attempts from an unfamiliar location, a user downloading an unusually large number of records in a short window) and surfacing them before they become incidents. The distinction between a system that logs and a system that alerts is the difference between a security record and a security posture.
Offboarding discipline.
The moment of departure is a high-risk transition. Organizations that treat it as a routine administrative step tend to leave gaps. Those that treat it as a security event, with defined timelines, structured checklists, and confirmation steps, close those gaps consistently.
Questions worth asking
Whether you are reviewing your current system or evaluating a new vendor, these questions cut through general claims about security:
- Can you show me how access permissions are configured? Not described — shown. A vendor that can walk through the actual permission model in the system is demonstrating something real. One that describes it in general terms may be describing an aspiration.
- Do we have a documented record of current user permissions? If the answer is no, the organization does not have a clear picture of who can access what, which means any assumption about the system’s security posture is unverified.
- When was the last time user access was formally reviewed? If the answer is “during implementation” or “I’m not sure,” the permission state of the system has been accumulating drift since then.
- What happens to system access the moment an employee is terminated? The answer should describe a specific, documented process with a defined timeline, not a general assurance that “IT handles it.”
- Is Multi-factor Authentication (MFA) available, and is it enforced for all users or optional? Optional MFA is not the same as MFA. For a system containing the sensitivity of data that an HRIS holds, the appropriate standard is enforcement, not availability.
Passwords matter. But they are the beginning of an access control conversation, not the end of it. What determines whether a breach succeeds is rarely the sophistication of the attack. It is the weakest point in the access chain — and that point is almost always somewhere between the login screen and the last permission that was never reviewed.
This is the third article in a series on HR data security and privacy for organizations operating in Southeast Asia. It builds on the earlier discussion of how data behaves across different states, focusing specifically on how access to that data is controlled in practice.
