An IT outsourcing company serves 40 clients. A full-service agency manages advertising campaigns, websites, and online stores for a dozen brands. An implementation consultant has access to the production environments of organizations they have worked with for the last three years.
Each of these companies possesses something that attackers actively look for: access to the systems of multiple organizations simultaneously. Not because they are a weak link, but because they are an effective vector. A single compromised access point on the service provider’s side can open the door to dozens of clients at the same time.
The problem is not that a service company has access to client systems. That is a necessary condition for providing services. The problem lies in how they manage this access. Who in the team has which passwords, how they are handed over during employee turnover, how they are updated after a change, and what is of crucial importance in the context of criminal liability – whether, in the event of an incident, the company is able to prove that it managed access correctly.
Why service companies are a specific target
The third party as an attack vector
Third-party access (from external vendors, partners, and service companies) is becoming one of the dominant vectors of security breaches. According to data from SentinelOne, in 2024, third-party connections were linked to 35.5% of all reported breaches. This is a 6.5% year-on-year increase. The risk escalates because vendor accounts often have broad permissions, lack session monitoring, and remain active long after the project is completed.
According to data from IBM and Secureframe, a breach involving a third party costs an average of $4.76 million – more than the average breach without an external vendor’s involvement. Moreover, detecting a breach caused by a vulnerability in third-party software takes an average of 210 days, and another 76 days to contain it (Imprivata).
The service company as a risk multiplier
For an attacker, compromising a single marketing agency with access to the advertising accounts of 20 clients is much more effective than attacking each client separately. The same applies to an IT outsourcer with access to the admin panels, servers, and infrastructure management systems of dozens of organizations.
Service companies operate in a model that naturally concentrates access. This is inevitable. The question is not how to avoid it, but how to manage access in a way that minimizes risk and demonstrates accountability.
What the problem looks like
IT outsourcing – one team, dozens of admin panels
An IT company manages the infrastructure of 35 clients. Each client has their own account in a hosting panel, access to a router, a login for a monitoring system, a password for a mail server, and an administrator account in the operating system. This is a minimum of 5–10 credentials per client – with 35 clients, this means over 200 passwords in circulation.
What does managing them look like without a dedicated tool? Passwords end up in an Excel sheet on a shared drive, are sent via Slack when the lead technician changes, or are copied by each employee into their own notes. When a technician leaves the company, nobody is certain how many passwords they took with them and which clients’ systems they can still log into.
A full-service agency – one account for the entire creative team
The agency runs campaigns for 15 clients: Google Ads and Meta campaigns, content management on websites (CMS), store management (WooCommerce, Shopify), sending newsletters, and social media moderation. Each client has a Google Ads account, a Meta Business Manager account, access to a CMS panel, a login for an email marketing platform, and FTP or hosting panel credentials.
A single client account is used by the account manager, SEM specialist, graphic designer, copywriter, and sometimes an external freelancer. The password circulates via email, Slack, or is entered manually based on a screenshot of a document. When a client changes a password because they “wanted to be sure” – the entire information flow starts all over again. Often with lost messages and operational delays.
Consultant / implementation specialist – temporary access that never expires
A consulting company carries out ERP system implementations, e-commerce platforms, and custom solutions for corporate clients. For the duration of the project, its employees receive access to testing and production environments. The project lasts three months. The access – often a year or longer.
The client rarely makes sure to revoke all access after the project ends. The consultant rarely reports that it should be revoked. As a result, the client’s production environment remains accessible to individuals who finished their work many months prior.
How to manage clients access without compromising the password
One client, one group
The foundation of access control in a service company is organizing credentials by client, not by employee. Each client has a dedicated group in perc.pass with an assigned set of users – those and only those who actually handle that account. A new employee joining a client’s project is added to the group. An employee ending collaboration with a client is removed. Passwords remain unchanged. Only who has access to them changes.
In the per-client vault model, it is also possible to precisely differentiate permissions: an account manager has access to login data for marketing tools but not to the hosting panel. A technician has access to the infrastructure but not to the advertising data. Everyone sees exclusively what they need for their work.
Changing access, not the password
One of the most common operational problems in service companies occurs when a technician or account manager leaves; you either have to change passwords for all client systems (and inform the clients or the remaining team) or keep the old password and accept the risk.
In perc.pass, this dilemma does not exist. Removing an employee from a client’s access group revokes their access to all credentials in that space immediately – without changing the passwords themselves, without informing clients, and without disrupting service availability for the rest of the team.
Password update in one place
A client changes the password to their admin panel. In a model without centralized management, this means: an email to everyone on the team, manual updates in an Excel sheet, and the risk that someone will try to log in with the old password for a week and lock the account.
With perc.pass, the password is updated in one place by the person who received it from the client. All other users in the group have access to the current data.
Accountability in the event of an incident
Operation history
When a client reports an incident – e.g., an unauthorized change in the system, suspicious activity on an advertising account, a modification of the server configuration – the first question directed to the service company is: who logged in and when?
Within system logs, perc.pass records every operation: who had access to what, and when. In the event of an incident, the company can present operational documentation within minutes: a list of logins, permission change history, and the date of the last access rotation. This is the difference between “we think that…” and “we can show that…”.
In the context of contractual liability towards the client and potential regulatory proceedings (GDPR, NIS2), the operation history is proof that the service company acted with due diligence – regardless of whose side caused the incident.
Elimination of uncontrolled channels
A password sent via email, pasted on Slack, or saved in a Teams message is a password that exists outside of any control. It is archived on communication providers’ servers, accessible from any logged-in recipient’s device, and impossible to delete without the certainty that it has vanished from all places.
A service company that can document that its access management process eliminates this channel because passwords are shared exclusively through an encrypted vault has a solid argument regarding security.
Immediate access revocation
When an employee leaves the company, and the company can pinpoint the exact hour their access to client systems was revoked – that is proof of proactive management. When it cannot pinpoint this hour, or when it turns out that access was not revoked at all, well… it has a significant problem.
In the access management model with perc.pass, every permission change is recorded with a date and time. Employee offboarding is not a process to be completed “whenever,” but an operation whose execution is documented.
If you want to make managing client access simple and secure – test perc.pass during a free trial period.