Credentials and Security Across Many Partners

"When did we last rotate the Cedar Freight key?" A pause, then someone opens the spreadsheet, then a longer pause. The key was installed by an administrator who has since left, for a partner contact who has also since left. It has never rotated because nothing ever made it. Securing one partner connection is a solved problem: create an account, exchange a key, restrict a folder, done in an afternoon. Securing forty of them is a different problem entirely, not forty times the same afternoon but a portfolio with its own failure modes. Credentials age at different rates. Partners change staff without telling you. The allowlist entry from an old office lingers after they move. And the question that matters is no longer "is this setup right?" Instead, ask: "across all of them, what is overdue? What is dormant? What would I be unable to answer if a security review asked tomorrow?"

Most estates handle this heroically. Each partner's security is as good as the administrator who set it up was careful that week. Nobody can see the whole. Heroism is not a control; it is a person, and it does not appear in the register. The alternative is to run partner credentials the way this series runs everything: as a program. A small set of non-negotiable practices applied to every partner, a register that makes the portfolio visible, rotation you can actually coordinate with other companies, and a defined ladder for the partner who will not cooperate.

This article covers that portfolio view. The life story of a single partner credential (how to exchange it safely, store it, and retire it) is deliberately not repeated here. That mechanics-level walkthrough lives in the partner credential lifecycle. Here we stay at the level of the estate: what must be true for every partner, and how to keep it true as the count grows. It is part of our B2B Partner Exchange series. By the end, the Cedar Freight key will have a rotation date. It may even have been rotated.

From One Careful Setup to a Portfolio

The portfolio shift is a shift in the questions you ask. Single-setup questions sound like: is this key strong, is this folder restricted, is this password in the credential store? Portfolio questions sound like:

• Which partner credentials are past their rotation date — and which have no rotation date recorded at all?
• Which accounts have not authenticated in ninety days, and does anyone know why?
• Which partners still authenticate with a password, and does each of those have the compensating controls we require?
• If one partner's credential leaked tonight, exactly what could the holder reach?
• Could we revoke any partner's access in five minutes, out of hours, without breaking anyone else?

None of these can be answered by inspecting one setup, however carefully. They require two things working together. One is uniform practices (so every partner's arrangement has the same shape). The other is a maintained record (so the shapes are visible in one place). The record is the partner register introduced in running partner exchange as a program. The credential columns of that register are what this article fills in.

Per-Partner Isolation: The Non-Negotiable Floor

Every practice in this article stands on one rule: one partner, one account, one folder tree. There are no exceptions, no matter how small the partner or how urgent the deadline. Isolation is what makes every other portfolio question answerable, because it makes every log line, permission, and credential attributable to exactly one company. Do not share an account "just for now". Now is a long time.

What isolation buys, concretely:

• Attribution. When the account is ALPINE, the server log answers "what did Alpine Parts do?" directly. With a shared account, every investigation begins with "which of the three partners using this login was it?" Logs cannot answer that question, ever, after the fact.
• Contained blast radius. A leaked credential exposes one partner's folder tree, not the estate. The general argument — sizing what one compromised account can reach — is laid out in the blast radius of one account. Partner accounts are its sharpest case because the credential's other half lives inside a company you do not control.
• Clean endings. Offboarding a partner becomes "disable their account" instead of "rotate the shared secret and re-coordinate with the two partners who remain". You will appreciate the difference the first time a relationship ends badly. The full ending is covered in offboarding partners without breakage.

One partner may have several unrelated flows. Consider one account per flow under the same partner code (ALPINE-ORDERS, ALPINE-PAYROLL) when those flows carry different data sensitivities or are operated by different teams on their side. The payroll credential should not be able to touch the orders tree, or vice versa. That is a judgment call; the per-partner floor is not.

On the server, isolation is ordinary configuration rather than architecture. In Sysax Multi Server, each partner is an account — built-in, or a Windows/Active Directory account where that is your model. Permissions scope it to its own folder tree. Its authentication method is set per account (public key or password), and IP allow rules narrow where it may connect from. The setup takes minutes at onboarding time; retrofitting isolation onto a shared-account estate takes a quarter. That is why the floor goes in on day one. Nobody has yet regretted the minutes.

Keys and Passwords at Portfolio Scale

The single-connection comparison of authentication methods is covered in authentication methods compared; at portfolio scale, three practical truths dominate:

Keys age more gracefully than passwords. A public-key setup generates no reset tickets, never gets emailed in a panic, and rotates by adding the new key alongside the old — no simultaneous cutover required. Multiply those properties by forty partners and the operational difference is stark. Password estates generate a steady drip of lockouts and reset requests from other companies' staff. Each one is an interruption with an identity-verification problem attached (is the person emailing you really Cedar Freight's new operator?). The email says so, and the email is very confident.

Passwords will not disappear from your portfolio anyway. Some partner systems cannot present a key; some partner IT departments cannot manage one. A realistic portfolio is mixed — keys as the default for everyone who can, passwords as the documented fallback for those who cannot. The discipline is that password partners are not "the same but weaker". Each one carries mandatory compensating controls. At minimum, these include a source IP allowlist (the account only authenticates from the partner's known addresses — see IP allowlisting and geo controls) and a password meeting your policy. The password is stored on their side however they store it, but on your side never in mail or chat.

The mix must be visible. Record the authentication type per partner in the register. The portfolio questions above — who still uses passwords, who lacks a rotation date — are register queries. They are only answerable if the auth column exists and is maintained. An estate that cannot list its password partners does not have a policy about them; it has a hope.

The Portfolio Practice Table

Here is the whole discipline in one copyable table: the practices applied to every partner without exception, what each means, and where you would look to verify it. This table doubles as a self-audit — walk your register against it once and you will know exactly where your portfolio stands. The first pass is usually humbling. Do it anyway.

Notice what the table does not contain: any secret. As always, the register records types, dates, and pointers; the credentials themselves live in your credential store and in the server's configuration. A register that could log in would be a very well-organized leak.

Rotation You Can Actually Coordinate

Rotation means replacing a credential on a schedule so a quietly leaked one has a bounded useful life. It is easy to decree and hard to do across company boundaries. That is because every rotation needs action from people who do not work for you. Estates that ignore this reality end up in one of two bad places: rotation that never happens, or rotation that breaks partner automation at two in the morning. I have been paged for the second and audited for the first. The fix is choosing a coordination pattern per partner and writing it in the register. Four patterns cover practice:

• Overlap window (the default for keys). The partner generates a new key pair and sends the public key. You install it alongside the old one. The partner switches at their leisure within the window — say, three weeks. You remove the old key when the logs show the new one in use, or when the window closes. Nobody needs a synchronized moment, which is exactly why key rotation succeeds where password cutovers fail. The hands-on mechanics and inventory habits are in key rotation and inventory.
• Deadline-driven. This pattern is for password partners, or partners who only act when pushed. You announce the rotation with the new-credential exchange method and a date measured in weeks. Their named credential contact executes. You verify by watching the first successful login and then retire the old secret. The announcement goes to the register's contacts — which is why the "contact confirmed at each rotation" practice exists.
• Cohort batching. Rotating forty partners individually, whenever each happens to come due, spreads the coordination cost into a permanent background drizzle. Batching partners into monthly cohorts means a handful of rotations per month, cycling the whole portfolio over a year. It turns rotation into a routine with a rhythm. It keeps any single month's load small and makes "are we current?" a one-glance question.
• Event-driven. Some rotations do not wait for schedules: the partner's transfer operator left, a laptop was stolen, a credential appeared somewhere it should not. These run immediately, through the same exchange choreography but compressed — and they are the reason the revocation path gets tested in calm times.

The Stubborn Partner Problem

Every portfolio contains one: the partner who ignores rotation notices, will not move off the password they set years ago, or cannot produce a key to save their lives. The wrong responses are the common ones — quietly letting their arrangement drift on forever, or fighting the same argument at every renewal with nothing written down. The right response is a ladder, climbed in order, with each rung recorded in the register:

1. Make compliance trivially easy. Most stubbornness is capacity, not malice. Send instructions written for their junior admin, offer a working session on a call, propose dates. A surprising fraction of stubborn partners are one thirty-minute call away from compliant.
2. Apply compensating controls unilaterally. Everything on your side tightens without their cooperation. Shrink the IP allowlist to their exact addresses. Cut permissions to the minimum the flow needs. Add alerting on their account's failures and oddities. Their risk contribution drops even while the argument continues.
3. Escalate through the business owner. The register names the person inside your organization who owns this relationship. Security requirements travel better in a commercial voice — "this is now a condition of the contract" — than in another IT email. This rung is why the business-owner column exists.
4. Grant a formal exception — with an expiry. If the business decides the relationship outweighs the requirement, that decision gets the full exception treatment from the standards article. In that case, the decision is documented, compensated, approved by name, and dated for review. The exception converts an argument into a managed risk.
5. Put risk acceptance in writing, above your pay grade. For the partner who defeats even the exception process, the last rung is a short written risk acceptance signed by whoever owns the risk. That is not the administrator. This is not bureaucracy for its own sake; it is the difference between "IT never fixed it" and "the business chose it" when the leak inquiry happens.

The ladder's virtue is that you are never stuck. At any moment, every stubborn partner is somewhere on it, moving, with a next step and a record — which is all a portfolio can honestly promise.

Watching the Portfolio

Practices decay without inspection, so the portfolio gets watched two ways — continuously by machines, periodically by people:

Continuously: authentication failures and anomalies should reach you before partners do. A burst of failures on one account often means a rotation happened on schedule but the partner's automation kept the old secret. That is annoying, fixable in an hour if you see it that morning. Failures on your outbound jobs mean the partner rotated something without telling you. A scheduled job platform can email on failure, as Sysax FTP Automation does. That turns the discovery from "the business asks where Friday's file went" into a notification at the moment of first failure. Repeated failures from addresses that are not the partner at all are a different animal — see monitoring authentication attacks.

Periodically: a scheduled review walks the register against the evidence. Look for overdue rotations and accounts with no successful login in ninety days (the method in finding stale and orphaned accounts works for partners too). Look for allowlist entries no longer matching the partner's announced addresses, exceptions past their review date, and contacts who bounced. Each finding becomes a task with an owner. The server's records make this concrete rather than ceremonial. With activity logged to a file or a database, as Sysax Multi Server does, "when did MERIDIAN last connect?" is a query. The review compares recorded truth against register claims. Fold this into the access-review rhythm your auditors likely already expect — the format and cadence are covered in periodic access reviews for transfer systems.

Kestrel Payroll's first register review found a partner key with no rotation date at all. It had been installed by an administrator two managers ago for a contact at Bluewater Bank who had since retired. The key still worked. It had, in fact, worked every night for four years, which is a fine record for a key and a poor one for a process. The review created a rotation entry. The bank's current contact was found through the business owner in about a week. The overlap window ran without anyone on either side noticing. The only casualty was the assumption that "no rotation date" meant "no rotation needed".

Partner accounts, one last note, are cousins of the service accounts inside your own estate — unattended, powerful, and easy to forget. The same hygiene instincts apply across both families, and service account hygiene is worth reading beside this article if internal accounts are also yours to keep. They usually are. Nobody mentions this at the interview.

Boring Credentials Are the Goal

A healthy credential portfolio is profoundly unexciting. Every partner is isolated to its own account and tree. The auth mix is visible in the register. Rotations arrive as scheduled cohort work with overlap windows instead of emergencies. Stubborn partners are parked on a ladder instead of in limbo. A monthly review mostly finds nothing. Excitement in credential management is another word for incident.

Get there in the order this article ran: isolation first (it is the floor everything stands on), then the register columns, then rotation patterns, then the watching. The lifecycle mechanics for each individual credential are in the partner credential lifecycle. The moment credentials get created is covered in the onboarding runbook. The moment they must all disappear cleanly is offboarding partners without breakage.

Frequently Asked Questions