In most companies, nobody knows exactly who has access to what. Until an incident occurs.
An employee who moved from the finance department to marketing three years ago still has access to the accounting systems. A subcontrator who finished a project six months ago can still log into the client’s environment. An administrator who left the company did not have all their permissions revoked because nobody had a complete list of them.
These are not exceptions. This is the picture of an IT environment in an organization that does not manage permissions systematically.
The problem of disorganized permissions is not solely a security issue. It is an operational risk: who can modify financial data, who has access to customer data, who can change the configuration of a production system. The answers to these questions should be available at any given moment. In most organizations, they are not.
Why permission management matters
Questions a company should be able to answer at any momen
Permission management comes down to three questions: who has access, what do they have access to, and to what extent. It sounds simple, but in practice, it is one of the most difficult elements of IT security to maintain because the state of permissions changes constantly. Employees change roles, subcontractors join, new tools are deployed, and old accounts remain active long after they have ceased to be necessary.
As Microsoft defines in the context of IAM, the goal of identity and access management systems is to ensure that authentication and authorization happen correctly with every access attempt, and that information about who should have access is constantly updated. Organizations grant different levels of access based on position, tenure, clearence, and project. The problem arises when these levels are not regularly reviewed.
IAM i PAM: a difference worth knowing
Two terms that appear in the context of permission management are IAM (Identity and Access Management) and PAM (Privileged Access Management). As SecurityScored explains, IAM manages the identities and access policies of all users – employees, contractors, and systems. PAM focuses exclusively on privileged accounts: administrators, service accounts, and users with access to critical resources. Both areas complement each other – and both require a systemic approach.
Skala ryzyka, czyli dane, które pokazują wagę problemu
According to data from ESDS, compromised privileged accounts are linked to approximately 80% of security breaches. The Verizon Data Breach Investigations Report 2024 indicates that 68% of all breaches involced a human element – error, privilege abuse, or stolen credentials. The average cost of data breach reached $4.88 million according to the IBM Cost of Data Breach Report 2024.
Disorganized permissions are not an abstract problem; they are a direct attack vector.
What permission chaos looks like
Privilege creep – permissions that nobody revoked
Privilege creep is the gradual accumulation of permissions that occurs with every change of role, project, or position – without the revocation of previous access rights. An employee who has moved between departments over three years may hold permissions to systems they haven’t used in a year. Each of these changes was justified at the moment access was granted. The problem is that nobody verifies whether that access is still needed.
As Zero Networks points out, over time, users accumulate access rights they no longer require, service accounts acquire uncontrolled permissions, and older applications demand excessive rights just to function.
Shared accounts – access without identity, identity without accountability
An account shared by several people – like “[email protected]”, a service account used by an entire team, or a shared login for an external system – is an account without an owner. When multiple people use a single account, it is difficult to establish who performed a specific operation. As Securivy emphasizes in its PAM analysis, the lack of transparency in privileged user actions resulting from account sharing causes difficulties in tracking activity and troubleshooting potential problems.
Employee departure without a full offboarding
An employee leaves. The account in Active Directory is deactivated. But what about the account in a SaaS application? In the client’s external system? In a project management tool where they configured acces themselves, outside the IT department’s knowledge? Each of these access points is a separate risk point.
Subcontractors and guests – temporary access that never expires
An external developer gets access to a repository for the duration of a project. The project ends, but the access remains. An external auditor receives a login for the financial system for a week. The week passes – the account still exists. This is a category of permissions that is particularly neglected in organizations without systematic access management, because no one feels ownership over the revocation process.
The principle of least privilege
The user gest only what they truly need
The Principle of Least Privilege (Least Privilege Access, LPA) states that every user, system, and application should receive only those permissions that are essential to perform specific duties – and nothing more. As BigID explains, LPA limits the damage an attacker can inflict if the compromise an account, because an account with limited privileges only grants limited access.
Implementing the principle of leas privilege begins with a question: what does the user trurly need access to in order to do their job? Not what might be useful to them, but what is essential.
Management by roles, not by inidviduals
Role-Based Access Control (RBAC) is a model in which permissions are assigned to roled, and those roles assigned to users, instead of configuring access individually for each person. A new employee receives a role corresponding to their position and automatically gains the permissions assigned to that role. A change in position means a change in role and an automatic update of permissions.
Permissions for the duration of the task, not forever
Just-In-Time Access (JIT) is a model in which privileged permissions are granted only for the duration of a specific task. They expire automatically upon its completion. An administrator need access to a production server for diagnostics: they receive it for 2 hours, after which access is revoked automatically. Specific timeframes for sessions mean the user must go through the authorization process for every single access attempt, eliminating the risk of unauthorized credential reuse.
How to implement permission control in a organization
Step 1: Inventory
Before making any changes, an audit of the current state must be conducted. The goal is to obtain a complete list of accounts, permissions, and systems, along with an answer to whether each access instance is justified. In most organizations, this audit reveals accounts of former employees, permissions “inherited” from previous projects, and access points that no one remembers exist.
Step 2: Segmentation
Permissions are grouped by roles and teams rather than assigned individually. Project resources go into dedicated project vaults. Financial systems go to the finance department’s access group, and production environments go to an administrative group with a strictly limited memebership. Segmentation ensures that changing one person’s permissions does not require modifying dozens of individual configurations.
Segmentation ensures that changing one person’s permissions does not require modifying dozens of individual configurations.
Step 3: Onboarding, offboarding and role change processes
Each of these events should have a defined, repeatable process for updating permissions. A new employee joins the appropriate groups based on their role, not based on a list copied from their predecessor. A change of position triggers an update in group memberships. An employee’s departure triggers removal from all groups and the revocation of all access rights.
Processes should be synchronized with the HR department, with every staffing change automatically triggering the corresponding update in the permission system.
Step 4: Regular permission reviews
Permissions should be reviewed regularly. The goal is to identify permissions that have become outdated without a clear initiating event. An employee who has not logged into a given system for six months probably no longer needs access to it. A service account that has not been used for a year should be verified.
The role of a password manager in permission management
Managing permissions within the scope of passwords and access to externall systems – SaaS applications, project tools, client systems – requires a tool that operates at the credential level, not just the domain account level. This is precisely where perc.pass complements identity management inftrastructure.
Central repository with group-level access control
Each deapartmental group in perc.pass has defined users with specified permission levels: full accessm read-only access… The IT administrator sees who has access to which resources, and every employee accesses only the passwords that are genuinely essential for their operations.
Secure access sharing
A user or subcontractor can log into a system via one-time share outside the organization. Perc.pass generates a one-tme, time-limited ling that can be additionally protected with a password. This eliminates the risk of access data being intercepted and falling into the wrong hands.
Immediate offboarding
Removing a user from perc.pass revokes their access to all passwords they wre assigned to – in a single operation. Without the need to manually reset passwords across dozens of systems. Whithout the risk of overlooking any access point.
Operation history – who, when, what
Within system logs, perc.pass records and gather every operation: logins, password chagers, access sharing, and permission revocations. In the event of an incident, the operation history allows for recontructing the actual state events. In the case of an audit, it provides operational documentation without any extra effort.
If you want to check how easily and securely you can manage passwords in your organization – test perc.pass during a free TRIAL. PYou can configure your first vaults and permission groups within a single working session.