Why NYC SMB leaders are rethinking “we’ll ask for the passwords”
Manhattan owners, COOs, and finance leads rarely want to run IT. You hire an MSP so you can focus on operations, revenue, and risk.
The trap is that “outsourced” can quietly become “single point of failure.” If your MSP has the only working admin path into the systems that run your business, you don’t have managed IT—you have managed dependency.
A quarterly “Keys, Control, and Continuity” audit is a 30-minute rotating drill (3 systems per quarter) that proves you can access and perform a read-only proof action—and validate recovery paths—using owner-held or dual-controlled credentials plus offline escrow.
The scenario: the five lockout moments that actually matter
MSP outage or dispute
Sometimes the risk isn’t malicious—it’s availability. If your provider’s ticketing, password vault, or staff coverage is disrupted, you still need a way to administer your environment.
Lost admin (departure, illness, or compromised account)
If the “one person who knows” is unreachable—or if an admin account is disabled after a security incident—your business still needs a clean, documented way in.
Registrar/DNS lockout
Registrar access is a business continuity issue, not a marketing issue. Without it, your email, apps, and website can go dark, and you may not be able to fix it quickly.
Firewall portal loss
If you can’t access your edge security device (or its cloud portal), your ability to respond to an incident, restore connectivity, or validate configuration is limited.
Backup console lockout
Backups don’t count if you can’t authenticate to the console and initiate a restore. Recovery is a control, not a promise.
The “Control Surface”: the 10–15 systems you must be able to reach
Think like a CFO: what systems can stop revenue, payroll, or operations?
Your “control surface” is the short list of platforms that can change identity, routing, access, or recovery. Most NYC SMBs have 10–15.
Below is a practical starting inventory—customize it to your stack and vendors.
Build your Control Surface Register using this baseline list:
- Domain registrar (where your domain is owned/renewed)
- DNS hosting (where records live—may be registrar or separate)
- Microsoft 365 tenant + Entra ID (identity, email, MFA, conditional access)
- Endpoint management (Intune, RMM, MDM, etc.)
- EDR/security console (Microsoft Defender, SentinelOne, CrowdStrike, etc.)
- Password manager / credential vault (shared vault + break-glass storage)
- Firewall management (local + cloud portal, if applicable)
- Wi‑Fi controller / cloud Wi‑Fi (guest and corporate SSIDs)
- Backup platform console (SaaS backup, image backup, immutable storage)
- Virtualization / server admin plane (Hyper‑V, VMware, cloud console)
- File platform admin (SharePoint/OneDrive admin, NAS admin)
- VoIP / UC admin (phone system portal, call routing)
- Website/CMS hosting + admin (WordPress, Webflow, Shopify, etc.)
- Payment/critical SaaS (payments, accounting, payroll, POS, practice management)
- Monitoring/status + incident communications (status page, mass notification)
Clarify the “business owner” for each control point
For each system, name a business owner (often CFO/COO) and a technical steward (often MSP). The business owner isn’t the daily operator—they’re the accountable party who can authorize emergency access.
Decide what must be dual-controlled vs. what can be delegated
The goal: keep your MSP powerful—but not irreplaceable
This isn’t about distrusting your provider. It’s about designing governance so a single third party can’t accidentally (or intentionally) become your only doorway.
Step 1: Classify each system by impact
Use three simple classes:
- Tier A (existential): identity, DNS/registrar, firewall, backups. Losing access can stop the business or prevent recovery.
- Tier B (major disruption): endpoint management, EDR, VoIP, core SaaS admin.
- Tier C (operational): systems where loss is inconvenient but not continuity-threatening.
Step 2: Assign custody rules by tier
For each system, decide whether access must be owner-held, dual-controlled, or delegated.
- Owner-held (recommended for Tier A): The business retains at least one working admin path that the MSP cannot block or reset unilaterally.
- Dual-controlled (recommended for Tier A and some Tier B): Actions require two parties (or two factors controlled by different people) to complete.
- Delegated (often fine for Tier C): MSP holds day-to-day admin, with documented emergency access available.
If you’re unsure where to draw the line, start with this rule: anything that can change identity, routing, or recovery should never be single-custody. That’s Entra/M365, registrar/DNS, firewall, and backup consoles.
Step 3: Define “acceptable shared custody” without creating chaos
Shared custody doesn’t mean shared passwords in a spreadsheet. It means:
- Named admin accounts (no generic “admin@” logins)
- Role-based access (read-only vs. change permissions)
- Clear emergency authority (who can approve use of break-glass credentials)
- Logging enabled and reviewed when emergency paths are used
Build two emergency admin paths per system (plus offline escrow)
Two paths prevents the most common failure mode: the “one working login”
A single admin account can fail for mundane reasons: MFA device lost, conditional access blocks, the MSP disables the user during troubleshooting, or the vendor locks the account.
Your standard should be two independent emergency admin paths for every Tier A system (and many Tier B systems).
Emergency path A: a “break-glass” admin with strict controls
This is an emergency-only account with:
- Separate identity from day-to-day admins
- Strong password stored in escrow
- MFA method that won’t disappear with a single phone (see below)
- Minimal privileges necessary to regain control (not “global everything” unless unavoidable)
Emergency path B: a second route that doesn’t share the same dependency
Examples include:
- A second emergency admin in Entra that uses a different MFA method
- A registrar account held by the business with a separate recovery email
- Local firewall admin credentials stored offline, independent of cloud portal access
Offline escrow: the “sealed envelope” or hardware vault procedure
Offline escrow is what you use when your password manager, email, or MSP is unavailable.
Options that work for NYC SMBs:
- Sealed envelope stored in a secure office safe, with sign-out logging
- Hardware vault (encrypted USB or dedicated device) stored securely
- Bank safe deposit box for the most critical credentials (slower access, higher assurance)
Include these items in escrow for each Tier A system:
- Emergency admin username
- Password (or recovery method)
- MFA seed/backup codes (where appropriate)
- Vendor support PINs or account numbers
- The “proof action” you will perform during the drill
Avoid putting recovery email addresses and MFA devices under the same vendor and same admin plane you’re trying to escape. Example: using a Microsoft 365 mailbox as the recovery email for your Microsoft 365 tenant can create circular lockout.
Name an “activation authority” before you need one
Pick one primary and one alternate activation authority—usually CFO/COO + owner—who can authorize opening escrow and using break-glass access.
Document:
- What constitutes an “activation event” (e.g., MSP unreachable, security incident, vendor lock)
- Who must be present (dual sign-off)
- How actions are logged and later reviewed
The 30-minute quarterly drill: rotate 3 systems, produce evidence
Why quarterly beats “we’ll test it later”
Credentials decay. MFA methods change. Vendors adjust security requirements. Staff turns over.
A quarterly rhythm catches failures while they’re still cheap to fix.
The drill structure (time-boxed)
Pick 3 systems each quarter. Run a simple test that proves access *and* control without making risky changes.
For each system, verify:
- Login works (using the emergency path or owner-held admin)
- MFA method works (backup codes available, authenticator still reachable, phone numbers current)
- Read-only proof action completes (export/view-only actions that show you have real control)
Examples of “proof actions” that are safe but meaningful
Use actions that demonstrate authority without altering production:
- Registrar/DNS: export the DNS zone file or take screenshots of authoritative records
- M365/Entra: view conditional access policies; confirm break-glass account exists and is excluded appropriately
- Firewall: view running configuration; confirm recent config backup is accessible
- Backup console: verify last successful backup; run a test restore to an isolated location (or restore a small file)
- Endpoint management: generate a device compliance report
- EDR: verify the tenant is accessible; view alert dashboard and policy assignments
Your proof action should be something a third party could understand later (auditor, insurer, lender, board). “I logged in” is weak. “I exported the DNS zone and captured the timestamped evidence” is governance.
Rotate systems so you cover the full control surface every year
With 12 systems, checking 3 per quarter covers everything annually. Tier A systems can be scheduled twice per year if your risk tolerance is lower.
The four templates that make this repeatable (and audit-friendly)
Control Surface Register (one page, living document)
Minimum fields:
- System name + vendor
- Purpose (what it controls)
- Tier (A/B/C)
- Business owner + technical steward
- Primary admin path + emergency path A + emergency path B
- MFA method(s) + recovery method(s)
- Escrow location + last rotation date
- Proof action defined
Escrow Checklist (what to store, how to store, who can open)
Include:
- Exact contents per system
- Packaging rules (sealed, dated, signed)
- Storage location and access log
- Activation authority names and signatures
Quarterly Drill Scorecard (evidence and outcomes)
Track:
- Systems tested
- Pass/fail for login, MFA, proof action
- Issues found (expired codes, wrong recovery email, disabled account)
- Owner sign-off and remediation due date
“What Changed” Change-Log (keeps your register honest)
Record changes that break access paths:
- MSP changed firewall vendor portal
- DNS migrated
- MFA policies tightened
- Backup platform switched
- Admin staff changed
How this differs from “switching MSP” checklists
Offboarding is an event; control is an operating rhythm
Most guidance is designed for the day you leave a provider. That’s necessary—but it’s late.
A quarterly Keys, Control, and Continuity audit gives you something better: continuous exit readiness while you keep your current MSP. It reduces friction, prevents surprises, and creates a simple paper trail that leadership can rely on.
Key Takeaways
- Your business needs a defined control surface (10–15 systems) where lockout equals disruption.
- Use a clear custody model: owner-held and dual-controlled for identity, DNS/registrar, firewall, and backups.
- Build two emergency admin paths per system plus an offline escrow process with named activation authority.
- Run a 30-minute quarterly drill testing 3 systems with a meaningful read-only proof action.
- Maintain governance evidence with four templates: register, escrow checklist, drill scorecard, and change-log.
Frequently Asked Questions
Do we really need offline escrow if we have a password manager?
Yes. If your password manager depends on SSO you can’t access, or the MSP administers the vault, it can fail at the exact moment you need it. Offline escrow is the last-resort path for Tier A systems.
Will my MSP object to this?
A mature provider usually won’t. This approach clarifies roles, reduces emergency chaos, and helps them prove good governance. The key is setting expectations: you’re not bypassing them day-to-day—you’re ensuring continuity.
How do we handle MFA for break-glass accounts without weakening security?
Use strong passwords plus tightly controlled MFA methods (backup codes stored in escrow, or a dedicated authenticator device stored securely). Limit use by policy, alert on sign-in, and review logs after any activation.
What’s the minimum we should test each quarter?
At minimum: M365/Entra, registrar/DNS, and backup console on a rotating basis. Those three systems influence identity, routing, and recovery—the core of continuity.
Does this replace disaster recovery planning?
No. It complements it. DR plans describe what you intend to do; this audit proves you can access the controls required to do it.
Take the Next Step
If you want confidence that your business can operate—and recover—without depending on a single MSP-held login, a quarterly Keys, Control, and Continuity audit is a practical starting point.
Your Expert Tech offers:
- Fixed-fee setup: build your Control Surface Register, custody rules, two-path emergency access, and offline escrow procedure
- Quarterly managed verification add-on: we facilitate the 30-minute drill, document evidence, and track remediation to closure
Contact Your Expert Tech to schedule a consultation and turn “we’ll get access when we need it” into a repeatable, provable control model.