The request arrives on day one and it does not look like a decision. Your delivery partner's lead needs to start: the repository, staging, the cloud console, the error tracker, the database — and since the sprint plan says Monday, could someone drop them into the client's Slack too. You forward it to whoever holds the credentials, it is done before lunch, and nobody writes anything down. That five-minute exchange is the part of the engagement your client's security review will eventually ask you to account for, and the only part you cannot reconstruct afterwards if you did not design it at the time.
Almost nobody does this on purpose, and there is a number for it. A UK government random probability survey of 2,180 businesses asks whether they have formally reviewed the cyber security risks their suppliers present. The answer: “Just over one in ten businesses said they reviewed the risks posed by their immediate suppliers (14%) and under one in ten were looking at their wider supply chain (7%)” (Department for Science, Innovation and Technology and Home Office, Cyber Security Breaches Survey 2025, published 10 April 2025). It climbs with size — “around a third of medium businesses (32%) and nearly half of large businesses (45%)” review their immediate suppliers. Read that from where you are standing. Your client may be in the 45 percent. You are the supplier being reviewed, and the thing under review is an access grant you made in a hurry.
Begin with the question the control frameworks answer and most agencies never ask: what kind of user is a partner's engineer? The standard treatment is unambiguous. NIST requires organisations to “Uniquely identify and authenticate organizational users and associate that unique identification with processes acting on behalf of those users,” and the discussion widens the category past the payroll on purpose: “Organizational users include employees or individuals who organizations consider to have an equivalent status to employees (e.g., contractors and guest researchers)” (National Institute of Standards and Technology, Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5, control IA-2). The same discussion notes that even where group accounts exist, organisations “may require unique identification of individuals in group accounts or for detailed accountability of individual activity.”
Translated: one account per human being, in that human's name, on every system. Never a single account shared by the partner firm, and never a login handed round a team. The shared account is tempting precisely because it hides the thing you are trying to hide — it does not surface an unfamiliar name in your client's user list — and it costs you the two capabilities you will actually need. You cannot revoke one person without breaking everyone. And when someone asks, eighteen months later, who ran that query, the honest answer is the partner's company name, which is not an answer.
Then restrict what those named accounts can reach. Seven national cyber security agencies put the customer's obligation in one paragraph: “Customers should ensure MSP accounts are not assigned to internal administrator groups; instead, restrict MSP accounts to systems managed by the MSP. Grant access and administrative permissions on a need-to-know basis, using the principle of least privilege. Verify, via audits, that MSP accounts are being used for appropriate purposes and activities, and that these accounts are disabled when not actively being used” (Cybersecurity and Infrastructure Security Agency, with NSA, FBI, NCSC-UK, ACSC, CCCS and NCSC-NZ, Protecting Against Cyber Threats to Managed Service Providers and their Customers, Alert Code AA22-131A, last revised 11 May 2022). It addresses managed service providers rather than build teams, and the difference matters less than it looks: the structural fact underneath is an outside firm holding standing credentials inside somebody else's estate, which is exactly what you have created.
Four tiers, and the boundary that matters is only one of them. A local development environment with synthetic data is the tier you grant within an hour of signature, to everyone, without a conversation — it is where the work happens and nothing in it can hurt anyone. Shared staging is where discipline starts, because staging is where production data goes to be forgotten about. Production read is a real engineering need during an incident and should be a named, time-bounded grant rather than a permanent one. Production write is the boundary. Below it, speed is the only thing you are optimising. At it, you are deciding who can destroy your client's business on a bad afternoon, and the right number of standing production-write accounts held by a firm you do not employ is usually zero.
The leak that actually happens is data, not access. Someone restores a production snapshot into staging because the bug only reproduces with real rows, and your client's customer records are now sitting in an environment with a weaker password policy, no alerting and eleven people who can read it — several of whom work for a company your client has never heard of. Nobody made a decision; a convenience became a standing condition. The instruction is boring and it holds: non-production environments get data with production's shape and not its contents, and the masking runs as part of the restore rather than as something a person remembers. Where that is genuinely impossible, the environment stops being non-production for access purposes and inherits every control above it.
Deploy credentials are the single highest-leverage line in this entire article. A partner engineer does not need the ability to push to production; they need the ability to cause a push to production, which is a different capability with a different blast radius. Merges to the release branch run through your pipeline, in your account, triggered by an approval from someone on your side. The partner holds no production deploy key at all. That converts a permanent standing risk into a reviewable event, puts a human name on every release, and quietly makes the engagement endable — the same reason the work should live in your repositories and CI from the first commit, an argument what belongs in a white-label subcontract makes on paper.
Whose identity provider issues the account is a commercial question dressed as a technical one. Three arrangements exist and they are not equivalent. Accounts created directly in your client's directory are the worst for you: they surface names and email domains you did not plan to explain, and revoking them requires your client to act. Accounts in the partner's own tenant are the worst for your client, because access then lives inside an organisation they have no relationship with. The arrangement that survives contact is accounts in your tenant, federated into whatever your client operates, so every person reaching those systems does so through an identity you issue and can withdraw in a minute without asking anyone. It also settles the presentation question on your terms rather than by discovery — who your client trusts when you subcontract is the discovered version.
Revocation is where every access policy actually fails, and the advisory names the failure. Its instruction to customers is that they “should be sure to disable MSP accounts that are no longer managing infrastructure,” with a note that reads like a description of your last engagement: “disabling MSP accounts can be overlooked when a contract terminates.” The same document asks organisations to limit their attack surface “such as disabling user accounts when personnel transition.” Both events are foreseeable and neither has an owner by default, so give them one. A named person on your side holds the access register; the subcontract obliges the partner to notify you in writing, within a stated number of hours, of any change in who is assigned; and a departure triggers a revocation you perform rather than request. The common case is not a contract ending — it is one engineer rolling off a live build while the rest of the team stays, which produces no paperwork at all unless you asked for it.
The test of all of it is a question you will be asked in arrears. Eighteen months from now, during a funding round, an acquisition or a breach at an unrelated vendor, your client's counsel or auditor will ask who had access to a particular system between two dates and what they did with it. Answering that by name is a design decision you either made at kickoff or did not. NIST states the principle in one sentence — “Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks” (SP 800-53 Rev. 5, control AC-6) — and isolation with an audit trail is a normal property of a well-built system, which is why the 150-branch platform we built for Concordia Colleges carries per-branch data isolation and audit trails as architecture rather than as a compliance afterthought.
A short list of things not to grant, in any tier, to anybody outside your firm. The account-owner or root identity, which is ownership rather than access and belongs to a different conversation — the handover: what you must receive covers why. The ability to create or elevate other users, because that is the power to defeat everything above it. Billing. The DNS zone. Bulk export of customer personal data. And anything that can turn logging off, since the audit trail is what makes every other control checkable afterwards. None of this is a statement about your partner's integrity. These are the grants whose absence costs a competent team nothing and whose presence you cannot explain to a security reviewer.
Expect this to arrive as a questionnaire, and expect the question to be blunt. Enterprise and regulated clients ask directly whether any third party has access to their systems or data, who they are, and what controls govern them. A principal answering from a register they already maintain is in a different conversation from one answering from memory — and the register, the sub-processor list and the flow-down obligations are the same artefacts, assembled once. That review is its own discipline: what AI changes in procurement and security review covers how it has moved, and security and compliance is where it lands as work.
The honest cost is speed, and pretending otherwise is how these policies get abandoned in week two. Every control above puts latency between a capable engineer and the thing they need. The resolution is not to relax the controls; it is to move the latency to where it is cheap. Grant the bottom tier instantly and generously — environment, repository, synthetic data, documentation, a working build on the first morning — and spend the friction budget entirely at the production boundary, where it buys something. An agency that inverts this, slow at the bottom and permissive at the top, has arranged to pay for the delay and carry the risk at the same time.
The test is one sentence long, and it is worth asking before the next kickoff rather than after the next incident. Could you produce, today, a list of every individual outside your company who can reach your client's systems, what each can do, who approved it and when it expires? If yes, you are running an engagement. If that list would have to be assembled by asking around, you do not have an access policy — you have an access history, written by whoever was quickest to say yes. Settling it before the first credential is issued is reasonable to expect of any white label software development partner, and equally reasonable for one to expect of you: the partner does not define the tiers and should not keep the register. An engineering assessment is where that gets reviewed against the engagements you are already running.
Find this useful? Tell Google to show you more of it.