Case Study: Securing a 100-Server Infrastructure

An infrastructure security case study: how a growing B2B SaaS company replaced VPN sprawl, shared break-glass keys, and opaque SSH habits with OnePAM—without freezing engineering velocity.

Executive summary

Northpeak Analytics runs a multi-tenant data platform on roughly 100 Linux servers split across two cloud regions, plus a small on-call rotation that touches production daily. Their board asked for a credible answer to a simple question: Who can access production, from where, and can we prove it? The honest pre-project answer was fragmented. After a phased OnePAM rollout, Northpeak achieved consistent just-in-time access, session visibility, and audit-friendly evidence—while keeping developers on familiar SSH workflows behind the gateway.

100
servers brought under centralized access policy
6
weeks from pilot to full production enforcement
0
standing shared break-glass SSH keys post-cutover

The situation: growth outpaced access governance

Northpeak’s infrastructure security case study begins where many teams live: success created scale faster than policy could follow. New services meant new instances, new contractors, and new “temporary” access paths that never fully retired. VPN profiles accumulated. Some engineers still carried long-lived SSH keys copied from laptop to laptop. Database tunneling through bastion hosts worked—but correlation across regions was painful, and incident drills exposed awkward gaps.

Signals that change was overdue

Three themes kept resurfacing in risk reviews. First, identity was inconsistent: contractors authenticated differently from employees, and emergency access sometimes meant sharing credentials in channels that were never designed to be a vault. Second, evidence was incomplete: logs existed, yet answering “which human touched this box during the outage window?” required manual stitching. Third, least privilege was aspirational: many engineers retained broad production reach because revoking it slowed them down.

Why “just logging” was not enough

Northpeak already shipped logs to a SIEM. The missing ingredient was a consistent control point: a place where access could be requested, approved, time-bound, and attributed to a person before a session ever reached a host. Without that, logs told a story after the fact—not a policy story auditors and leadership wanted in advance.

Goals for the OnePAM deployment

The program sponsor (VP Engineering) and the interim security lead aligned on outcomes that map cleanly to modern privileged access management: eliminate shared credentials for routine work, reduce standing privilege, preserve developer speed, and produce repeatable evidence for SOC 2-style questions. They explicitly rejected a “big bang freeze” that would stall releases for a quarter.

  • Route production SSH through OnePAM with MFA-backed identity for every interactive session
  • Replace permanent keys with short-lived, policy-scoped access tied to tickets or on-call rotation
  • Segment by role so data-plane engineers, platform SREs, and break-glass owners had different approval paths
  • Record sessions for the highest-risk cohort first, then expand based on noise tolerance
  • Keep rollback credible by maintaining a narrow emergency path documented out-of-band (not in chat)

Architecture: how OnePAM sits in front of 100 servers

Rather than installing agents on every host on day one, Northpeak treated OnePAM as the access edge: users authenticated to OnePAM, policies decided what targets were reachable, and sessions were brokered with clear attribution. Over time, they tightened host-side expectations (for example, restricting direct paths that bypassed the gateway), but the first win was centralizing trust where humans actually clicked “connect.”

Northpeak: OnePAM in front of a 100-server estate People Employees Contractors On-call OnePAM gateway SSO · MFA · policies Just-in-time access windows Session recording & audit trail No shared production passwords in chat Region A — ~55 servers App tiers · workers · caches SSH sessions brokered via policy Kubernetes jump paths phased in later Region B — ~45 servers DR replicas · batch · observability stack Aligned approvals for cross-region work Uniform attribution in one audit timeline Infrastructure security case study pattern: consolidate trust at the access edge first

OnePAM becomes the control plane for human access: authentication, authorization, time bounds, and evidence—before traffic reaches hosts in either region.

Phased rollout: what happened week by week

Northpeak’s program manager insisted on measurable milestones. Week one focused on inventory: mapping owners, naming conventions, and the “why does this host exist?” debt that always appears around server sixty. Week two stood up the pilot group—platform SREs only—so early policy mistakes did not impact every product team. Weeks three through five expanded cohorts, tuned approval SLAs, and trained support on the new on-call drill. Week six flipped enforcement for remaining production paths except the documented emergency exception.

Change management that actually stuck

The team published a one-page “how we SSH now” guide, recorded a twelve-minute walkthrough, and added a Slack shortcut that linked directly to access requests. They also scheduled office hours twice weekly for two sprints. The lesson for any infrastructure security case study is that tooling adoption is a communications problem disguised as a technical one: if requesting access feels slower than the old shortcut, people will route around you.

Dimension Before OnePAM After OnePAM
Primary risk Long-lived keys & inconsistent MFA Short-lived access with MFA at the gateway
Evidence Fragmented logs, heavy manual correlation Unified session trail tied to identity & ticket
Emergency access Opaque break-glass habits Documented path, rare, tightly audited
Contractor governance Varied onboarding steps per team Same policy engine as employees, scoped roles

Outcomes, lessons learned, and what we would do again

Within the first month of full enforcement, Northpeak’s security retrospectives changed tone. Questions that previously took hours—who accessed a compromised dependency host, whether access aligned with the change window, whether a contractor’s session was recorded—became answerable in minutes. Engineering noted fewer “access ping-pong” threads because approvals were explicit and time-bounded rather than implied by membership in a broad group.

The biggest lesson was sequencing: win the access edge before debating perfect host posture. Host hardening still mattered, but centralizing trust let Northpeak demonstrate control while parallel workstreams continued. A second lesson was kindness in policy design: overly short windows created approval fatigue; tuning durations by role reduced noise without sacrificing security intent.

How your team can run the same play

You do not need a mythical security army to start. You do need a sponsor who will protect calendar time for cleanup work, and a small group willing to pilot honestly. Begin with the noisiest risk—usually production SSH or shared credentials—then expand protocols and environments as confidence grows.

See OnePAM on your infrastructure

Spin up a trial, connect a pilot group, and ship audit-ready access without the traditional PAM deployment marathon.

Start free trial

Mid-size teams routinely secure 100-server footprints faster when they consolidate privileged access behind a modern gateway, pair it with just-in-time policy, and treat developer experience as a first-class requirement. If your organization is preparing for a compliance cycle—or simply tired of guessing who had production keys last Tuesday—Northpeak’s journey is the infrastructure security case study arc worth copying.

OnePAM Team
Security & Infrastructure Team