Why People Should Care About TMS Security

Businesses often have strict security policies within the company. ISO 27001, for example, enforces the use of company-owned devices, clear policies about who can access GitHub and website CMS, and who can modify which data, and more.

But look what happens when a company decides to become multilingual:

1. Data goes to TMS
2. The company might hire a multilingual translation agency (Multi-Language Vendor, MLV)
3. MLV would hire a single language agency (SLV)
4. SLV would hire a freelance translator, who can share their computer with their older son to play computer games (and install its plugins), and the same computer is used for hobbies that require software from different, unknown developers.

Note: It’s hard to find specialists for Japanese, Arabic, Portuguese, and many other languages who would all work together in your office in Vienna, for example. And because translation agencies often don’t have enough steady work for full-time staff, the truth is that our industry mostly relies on freelancers. This, of course, impacts security in the translation industry.

When buying translations, companies grant access and edit permissions to their website CMS and GitHub to a person who doesn’t follow or even know their security policies.

Allow freelancers with an unknown security profile to edit the content on your main page? How big a risk is that? A huge one.

Here Is One More Story Before We Jump Into Configuring Crowdin

We recently learned an interesting fact about how the hacking industry works from a security researcher. There are lots of hackers out there that just create malware – they don’t care about the content of your computer. Their purpose is to make victims download their malware or miss a browser update, thereby infecting their computers via an outdated browser. Right after infecting a victim, they publish this information on the dark web (passwords, files, apps, and anything else they can find).

So, technically, if someone wants to attack your company, they don’t even need to break in themselves. They can just wait and get alerts when any computer that has access to your company’s data gets infected, and its information shows up on the dark web.

Or, in a localization industry case, when a freelance translator’s computer is infected.

Remember those security risks freelance computers bear? To fight this translation services security risk, we need controls.

Zero Trust Principle

Zero Trust, in simple words, is when we don’t rely on agreements and promises but instead rely on technical controls.

Companies that create processes asking people with access to company data not to download third-party software might forget that: hacker can trick people to download malware with phishing attack, accidental downloads, people can forget about policies, new hires might not prioritize those rules, and sorry to say but someone can think “I don’t think downloading this wonderful computer game plugin is a big security threat.” (or browser extension, or NPM package, or Google Drive plugin)

What we want to say is: Unless you enforce security, you can’t guarantee you have a secure setup.

Although we mention malware downloads as a security threat, we won’t discuss how to protect yourself from them. Instead, in this and future posts, we will describe situations in which the user’s computer is already infected or their credentials have been compromised.

Now, let’s go through some security risks and how to mitigate them using the Crowdin Zero Trust approach and the features we have.

Manager Accounts Security

Passwords alone are insecure. No one should rely on them exclusively. There are so many ways to compromise passwords that we won’t even list them here.

What happens without proper authentication: Your manager reused a password from another website. That site got breached, and because the same password was used, hackers gained admin access to all your translation projects.

For best security, you should configure SAML access, where your IdP can check if the login to Crowdin is being made from a secure, company-owned device (and many other security checks).

Setting up your company’s IdP might be tricky for linguists, as linguists are not company employees. That’s why we recommend SAML for all Crowdin managers – those Crowdin users who have the most permissions. Linguist access should be secured as described below.

Recommendation: Enforce SAML for managers.

Linguist Accounts Security

By default, Crowdin is configured to verify devices for all Crowdin users in both Crowdin products. This is the “proto-2FA” which is good enough. Everyone hates that step, but this is to verify that a hacker who stole a password cannot access Crowdin without having access to the user’s email. But if a hacker manages to get into a user’s email as well, this layer becomes useless. That’s why Crowdin has an additional level of security.

What happens with weak 2FA: Phishing sites clone Crowdin’s login page, steal your linguist’s 2FA code, and access all your pre-launch marketing content.

Crowdin Enterprise lets you enforce 2FA across your organization. Its common implementation is an Authentication App on a smartphone (not connected to email), but it’s quite easy to steal by phishing the user, for example, by cloning a Crowdin login page and tricking a person into entering that code there.

That’s why we strongly recommend enforcing Biometric 2FA or passkeys (the second one is already available at Crowdin). You should be cautious as linguists might use older computers with no biometric scanners, but modern browsers offer the use of smartphones (which typically come with biometric scanners) to serve as biometric 2FA on desktop.

Recommendation: Enforce biometric 2FA/passkeys for all non-manager Crowdin users.

Authentication Methods

For convenience, Crowdin provides a set of authentication methods, such as “Login with Google” and “Login with GitHub.”

What happens with multiple auth methods: Linguist’s compromised X account becomes a backdoor to your entire localization pipeline.

It’s recommended to disable all methods except SAML and Passkey, for example, to reduce the attack surface. If one of the Crowdin users’ GitHub accounts is compromised, Crowdin won’t be at risk.

Recommendation: Limit authentication methods to the most secure ones only.

API Tokens

API is great. It’s wonderful; it allows creating great automations that can save a lot of time. The problem with API tokens can be easy to steal if not handled correctly. If the API token is compromised, consider it a hacker with login+password+2FA to access Crowdin on your behalf.

What happens with unmanaged API tokens:That API token created 3 years ago and forgotten in the Downloads folder, gets uploaded to open repo on GitHub by mistake. Now everyone can access your TMS.

If you don’t use API integrations, disable the creation of personal tokens.

If you do, harden the setup by enabling a Maximum Token Lifetime (e.g., 30–90 days) to force rotation. People often create tokens and forget them, in downloads, scripts, or old backups, so a year-old token can become a serious exposure if discovered.

When you (or your team) need a token, apply the principle of least privilege. In Crowdin, you can restrict both scopes (what the token can do) and projects (where it can do it). Avoid “all scopes” and “all projects.”

Bad: full-access token across all projects.

Good: read-only access to Tasks in the Marketing Emails project.

Audit tokens regularly in the User Access Tokens section of Crowdin Enterprise settings and check the owner, last used, and expiry. Plus, delete anything unused or unauthorized.

Recommendation: Enforce token rotation and regularly audit existing tokens.

IP Allowlist

This is a Crowdin Enterprise feature that lets you restrict which computer networks can access your Crowdin organization.

What happens without IP restrictions:The hacker got your manager credentials. They did this by a phishing / spear-phishing attack. A hacker can now log in to your Crowdin project.

If you can make both Crowdin managers AND linguists work from the same computer network, this is a great way to protect your Crowdin Enterprise organization. Hackers won’t be able to access it unless they get into your VPN.

Recommendation: With the IP whitelist feature enabled, hackers cannot log in to your Crowdin Enterprise account, even if they have the correct credentials (unless they hack into the VPN tool).

Idle Session Timeout

What if a Crowdin Enterprise user uses a shared computer in a hotel to access Crowdin? If they forget to log out, the next user of that computer can be a random teenager, now having access to your corporate data (with edit permissions). Check a more realistic scenario also:

What happens without a session timeout: A linguist’s laptop infected with rootkit malware wakes up at night while they sleep. Hacker has 8 hours of uninterrupted access to manipulate translations.

Unless you can guarantee that access to Crowdin is enforced on company-owned devices with no risk of malware, it’s recommended that the Idle Session Timeout be set to 20 minutes. It means Crowdin will log out users after 20 minutes of inactivity. This is definitely not convenient, a translator would have to log in to Crowdin after lunch. However, the risk is too high to be acceptable.

Recommendation: Set idle timeout to 20-30 minutes maximum.

Crowdin Apps

We love apps. However, when installed, apps gain access to your data.

It’s recommended to check who developed the Crowdin app and ask about its security. When installing third-party apps, make sure you have all required data processing agreements in place. When building custom apps, make sure a software developer and/or security engineer reviews its code.

Recommendation: Audit apps before installation.

Permission Granularity

Big organizations with multiple teams in Crowdin should have this enabled. This means your software development team can’t access marketing content and vice versa.

If an attacker compromises a user account with limited permissions, they gain access only to the parts of the system that the user is allowed to see. They cannot reach the rest of your projects or sensitive areas of the workspace. This simply limits how much damage they can do.

Recommendation: Enable project-level and team-level access restrictions.

Offline Translations

Truth be told, there are linguists who prefer translation tools they’re used to. Crowdin offers an “offline translation” feature that lets linguists download XLIFF files, translate with their preferred tool, and upload the translations back to Crowdin. While we have this feature, we encourage everyone to never use it.

Linguist devices are often less secure than a cloud service. Also, neither you nor we know where those files will travel after downloading from Crowdin.

We recommend turning off “Allow Offline Translation” in all your projects (starting in 2025, it’s turned off by default).

By the way, there are major advantages of translating in the Crowdin Editor. Linguists can raise issues on the segment level if they need the manager’s help. Crowdin Editor provides a lot of contextual information that just can’t be transferred to third-party translation tools, as those tools don’t have concepts for that kind of context (like segment-level screenshots).

Recommendation: Disable offline translations completely, in every project.

Task-Based Access

A general recommendation across all major security standards is “limited access” – all users should have access only to the data they need to work on.

By default, when you invite a linguist to a Crowdin project, they can access all files in that project (in their language or ALL languages, if not restricted). If you see risks in linguists accessing the whole project (e.g., you’re localizing a computer game with millions invested in the scenario and no one should see the whole scenario before the game is published), this option should be turned on.

Recommendation: Enable task-based access for sensitive projects.

Account Provisioning

Allow Signup

Make sure the “Allow Signup” option is not enabled in your Crowdin Enterprise.

What happens with open signup: Random people create accounts and gain access to projects with improper permission settings.

Many organizations might have lower security requirements or have a need for people to log in to Crowdin without being invited. If you don’t need that, make sure this option is disabled.

Admin-Managed Invitations

Another option to keep disabled. If you can build a process that only allows admins to invite users, do that.

What happens without controlled invitations: The project manager invites their friend to “help out quickly with a technical problem”.

A recommended, secure, and enterprise-ready account provisioning workflow is to use the SCIM User Provisioning app.

Recommendation: Disable self-signup and enforce admin-only invitations.

Ghost Accounts

There are many reasons why companies might end their relationship with a freelancer. For security purposes, it’s essential that companies ensure former contractors lose access to Crowdin immediately, or at the very least, within a reasonable timeframe. The key point is that access must be revoked completely and shouldn’t linger indefinitely.

What happens with lingering accounts: A freelancer who stopped working with you 2 years ago gets their email hacked. Now hackers have access to your current projects through this forgotten account.

These ghost accounts can still be compromised, and even when a linguist no longer uses Crowdin, a hacker could gain access to Crowdin through their old account.

The Auto Lock Inactive Users app does exactly that and is recommended for securing Crowdin Enterprise.

Recommendation: Automate deactivation of inactive accounts.

Final Thoughts

Security is so vast that we can’t cover every aspect of it in one article – webhook security (should include a “salt header”), audit logs streaming to a SIEM with alerts, regular security training for freelancers, a bazillion more.

What we believe: In the world of TMS security, paranoia is just good planning. Starting with the things mentioned above improves security posture significantly.

Crowdin takes security seriously, running a HackerOne bug bounty program where we pay researchers to find and report vulnerabilities. Currently, the program is private, inviting a select group of security researchers to participate.