An MSP that wants to resell a password manager under its own name needs five things: its brand on what the client sees, each client's data kept apart, a way to bill, control over which of its own technicians can get in, and an honest list of what the product doesn't do. The logo is the easy part. Billing and day-to-day admin across twenty clients are where it gets hard.
SecureGate Card's Business plan covers branding, client separation and technician roles inside each client. It doesn't have a partner console or reseller billing yet. If you manage dozens of client tenants from one screen today, read what we don't do before anything else.
The checklist
| What you need | Why it matters | SecureGate Card today |
|---|---|---|
| Your brand on the client's screens | The client should think of it as your service | App name, logo, main colour and which features show, on Business |
| Your own domain | vault.yourmsp.co.uk reads as yours, ours doesn't |
Yes, set up with us: we configure the DNS and certificate |
| Client data kept apart | One client must never see another's vaults | Each client is its own organisation |
| Roles for your technicians | Not every tech needs billing or every vault | Roles with granular permissions per organisation |
| An audit trail | You'll be asked who did what, and when | Organisation audit log |
| One console for all clients | Twenty logins to twenty tenants doesn't scale | Not yet |
| Billing to you, not the client | You set the price and own the relationship | Not yet. Each organisation is billed through Stripe |
| SSO and automatic provisioning | Leavers get removed without someone remembering | Not yet. No SSO, SAML or SCIM |
Your brand, not ours
On Business, an organisation can set its own app name, logo and main colour, and switch features on or off. The branding is picked from the domain someone signs in through. Your clients go to your address and see your name.
The custom domain isn't self-service. It's set up with us: we agree the DNS records with you, install the certificate and check it works. That takes an email exchange, not a form. We'd rather do it with you than have a client hit a certificate warning on day one.
Before you promise a client the product is yours end to end, list every place they'll meet it: the web panel, invitation emails, the browser extension, the phone app. Ask any vendor, us included, which of those carry your brand and which carry theirs. A client who finds the vendor's name in a store listing will ask why. Better that you know the answer first.
Switch off what they won't use
Hiding features matters more than it sounds. If a client only needs shared passwords, switch off the rest. Fewer buttons means fewer support tickets, and support tickets are where your margin goes.
One client, one organisation
Each client is a separate organisation with its own members, departments, vaults, roles and audit log. One client's vaults don't appear in another's. That's the property you can't compromise on: a technician mistake in one client must not leak into another.
Inside each client you can split vaults by department. Finance gets the bank logins, the office manager gets the supplier portals, and everyone shares the company-wide vault. Members only see their own department's vaults and the company-wide ones. The business page shows how that's set up.
The cost of that separation is that there's no single place to see all your clients. You sign in to each organisation on its own. With five clients that's fine. With fifty it isn't.
Your technicians
Roles are where you decide what your own staff can do inside a client. Permissions are granular: managing the organisation, departments, roles, members and vaults; reading and writing vaults; setting policies; branding; billing; reading the audit log.
A sensible split for an MSP:
- Account lead. Manages members, departments and roles. No billing unless they're the one paying.
- Technician. Reads and writes vaults. Doesn't manage members.
- Client admin. The client's own office manager. Manages members and reads the audit log, so they can see what your team did.
That last role matters. Giving the client the audit log is how you show them what your team has been doing in their account.
If a technician's card goes missing, it can't open their account on a new device by itself. A card or NFC tag alone never does: it also needs a PIN, the master password, approval by email, or a device that's already trusted.
Network restriction is something you can sell
Business also lets an organisation limit access to a list of IP ranges. Every authenticated request from outside them is refused, not just the login, and administrators can be left exempt. For an MSP that's useful twice: you can sell office-only access to a client's finance team, and you can add your own office range so your technicians still get in.
Billing
Each organisation pays through Stripe. Business is €8 per user a month, or €77 per user a year, excluding VAT. Seats can be added at any time, the 14-day trial doesn't ask for payment details until you subscribe, and the subscription can be cancelled from the panel. Full numbers are on the pricing page.
What there isn't is reseller billing. We don't send you one invoice for all your clients. Today the workable setup is that your company owns each client's subscription, pays it, and invoices the client with your own markup. It works. It's also manual, and you should know that before you build a service around it.
A worked example: a client with 15 staff on Business costs €120 a month, or €1,155 a year on annual billing. What you charge on top is your call.
What we don't do yet
These are the gaps an MSP will hit. None of them has a date we'd stand behind, so don't plan around them.
- No partner console. There's no multi-tenant view across clients. Bitwarden's Provider Portal and 1Password's MSP edition both have one.
- No reseller billing. Each organisation is billed on its own.
- No SSO or SAML. Staff sign in with SecureGate Card's own methods, not with the client's Microsoft or Google account.
- No SCIM or automatic provisioning. When someone leaves the client, a person removes them by hand.
- No iOS app. If a client's staff are mostly on iPhones, that's a problem today.
- Not zero-knowledge. We encrypt vaults with AES-256-GCM on our servers, with a key we hold. Bitwarden and 1Password encrypt on the device before anything leaves it. Some clients will ask. Tell them the truth.
Questions to ask any vendor, us included
- Which screens and emails carry my brand, and which carry yours?
- Can I use my own domain, and who handles the certificate?
- Is each client fully separate, audit log included?
- Can my technicians manage vaults without touching billing?
- Who gets the invoice: me or my client?
- How do leavers get removed, and who has to remember?
- Can the vendor read the vault data?
- What happens to a client's data if I stop reselling?
When it fits, and when it doesn't
It fits an MSP or IT consultancy with a handful of small clients, five to fifty people each, that want a password manager that looks like part of your service and is priced per seat. It fits better still if those clients have a finance team you can sell office-only access to, or staff who already carry access cards. The Bitwarden and 1Password comparisons set out what the bigger names do better.
It doesn't fit if you manage dozens of tenants and need one console to do it, if you need us to invoice you rather than your clients, or if your clients sign in through Microsoft or Google and expect leavers removed automatically. It doesn't fit a client whose rule is that the provider can't read the vault. For any of those, look at Bitwarden's Provider Portal or 1Password's MSP edition first.