The PAM Academy · Module 5
Every privileged access management platform looks flawless in the vendor’s own environment. The demo estate is clean, the accounts are tidy, the integrations were built the week before, and nothing has been running for seven years on an operating system nobody will admit to owning. The question that matters is not how the platform behaves in their environment. It is how it behaves in yours, at your scale, in year five.
Technology selection is where privileged access management programmes quietly go wrong. Teams buy on feature lists rather than requirements, discover the connector they needed was never included, find that session recording consumes more storage than anyone budgeted, or learn during the first outage that the security tool has become the outage. The fix is not a longer feature comparison. It is a disciplined method: write your requirements before you meet a vendor, choose a deployment model that matches your risk, price the integrations before you sign, and prove the platform on your own systems.
This module sets out that method. It covers the case for automating privileged access at all, the three deployment models and their trade-offs, what belongs in a Request for Information, how to design a proof of concept that produces evidence rather than reassurance, and how to integrate a platform with the identity, security and operations tooling you already run.
Module 5: Sofia, Solutions Engineer
Part of the PAM Academy. Every module follows one person through a real privileged access problem, so the lesson lands in the context of the job you actually do.
Who this module is for
Solutions Engineer / Pre-Sales Engineer
A repeatable evaluation framework for scoring platforms against written requirements instead of against each other’s marketing.
Security Architect
A way to match deployment model, integration topology and resilience design to the organisation’s actual risk profile and regulatory obligations.
IAM Engineer
A concrete map of the integration points that decide whether a platform manages the estate or only part of it, from directories and MFA through to CI/CD pipelines.
CISO / Head of Security
A defensible selection process that survives audit and board scrutiny, and a clear view of the costs that never appear on the licence line.
IT Operations Lead
Sizing, availability and performance criteria to test before signature, so the platform does not become the reason work slows down.
The problems this module solves
Buying on the demo, not on the requirements
Vendor environments are built to make the product look effortless, and every platform passes that test. Organisations that shortlist before writing down what they need end up negotiating against a feature list somebody else designed, and only discover the gaps when the platform meets real systems.
Integration costs discovered after signature
Licences are the visible line in the budget. Connectors, custom scripts for in-house applications, and breakage at each upgrade are the invisible three. A platform that cannot reach the legacy systems, network devices or pipelines where credentials actually live manages only the easy half of the estate.
A platform that works at fifty accounts and fails at five thousand
Performance and scalability rarely appear in a demonstration because demo estates are small. In production, session streams, credential exchanges and audit logs generate real network and database load. If the platform is slow, people build workarounds, and a bypassed control protects nothing.
The wrong deployment model for the regulatory reality
Choosing cloud when data residency rules forbid it, or on-premises when the team has no capacity to patch and run it, creates a problem that no amount of configuration fixes. The model has to match the organisation’s size, industry, regulatory environment and technical capability.
What you will learn
- Understand the PAM technology landscapeKnow the core capability areas of a privileged access management platform, how they fit together, and what the consolidated view of accounts, assets and activity actually depends on.
- Select solutions that fit your needs and environmentBuild weighted requirements, run a structured RFI, shortlist on evidence, and score vendors against your own criteria rather than against competitor comparisons.
- Choose the right deployment approachCompare on-premises, cloud and hybrid deployment across control, cost, maintenance, scalability and data sovereignty, and justify the choice against your risk profile.
- Integrate PAM with your IT and security ecosystemPlan connections to IAM, directory services, MFA, SIEM, ITSM ticketing, cloud platforms, databases, network devices, containers and CI/CD pipelines, and price them before contract.
- Optimise and scale for the long termDesign for load balancing, high availability, database performance and automated operations so the platform absorbs growth instead of becoming a bottleneck.
Why automate privileged access instead of managing it by hand?
Be clear about what you are buying. Most organisations start with manual controls: a spreadsheet of administrative accounts, a shared credential store, a password change performed when someone remembers. That holds until the estate grows past what one team can carry in its head. Automation changes eight things.
- Reduced human error. Manual controls are susceptible to misconfiguration, and a misconfigured privilege is a vulnerability in uniform. Automation applies pre-determined measures the same way every time.
- Time and resource efficiency. Account provisioning, credential rotation and de-provisioning run without constant human attention, freeing skilled people for work machines cannot do.
- Improved audit and compliance. Automated systems track and log every privileged activity, producing complete and consistent records where manual record-keeping is patchy. Auditors notice the difference.
- Increased security. Threats meet an automated response at machine speed. A rapid response prevents breaches that a slower manual one would merely document.
- Continuous monitoring. Twenty-four hour coverage is impractical for people and native for systems. Suspicious activity is detected whenever it happens, not whenever someone is on shift.
- Scalability. Manual privilege management gets harder as the organisation grows. Automation scales with the estate rather than with headcount.
- Consistency. Access rights and restrictions applied uniformly across a large, complex organisation, which is exactly what cannot be sustained by hand.
- Enforced least privilege and just-in-time access. Privileges granted only when needed and revoked when no longer required, closing off both privilege abuse and idle accounts waiting to be exploited.
The single pane of glass
The summary benefit is consolidation. A platform pulls privileged account and asset information from multiple sources into one interface: a unified view of accounts, assets and metrics, efficiency because nobody toggles between tools, consistency because there is one system to train people on, and faster decisions because patterns and anomalies surface when the whole picture is visible. Note the dependency. That consolidated view only exists if the underlying systems are wired together through APIs and integration tooling.
How to choose a PAM solution: requirements before vendors
The most useful rule in platform selection is sequencing. Requirements first, vendors second. It is very difficult to define a requirement honestly after you have seen a feature that nearly meets it.
Start from the discovery work: the inventory of privileged accounts, the systems they sit on, the use cases they serve and the regulatory obligations attached to them. Turn that into a weighted requirements set, with mandatory criteria separated from desirable ones, and agree the weightings with the people who will live with the decision before scoring begins.
Run the stages in order
- RFI (Request for Information). Broad, exploratory, used to understand the market and pre-select a shortlist.
- RFP (Request for Proposal). Detailed evaluation against your specification, with structured demonstrations against your scenarios rather than the vendor’s.
- Proof of concept. Evidence from your own environment.
- RFQ (Request for Quotation) and contract. Commercial terms negotiated from a position of market knowledge.
Evaluate categories, not brand reputation
The market contains several recognisable categories: enterprise vaulting and session management suites, cloud-first platforms delivered as a service, endpoint privilege management tools, secrets management products aimed at pipelines, and identity governance vendors extending into privileged access. Work out which category or combination matches your estate, then compare products within it. Scoring one category against another on a shared checklist produces a meaningless average. Vendor behaviour is data too: a pitch that spends more time attacking competitors than understanding your environment tells you something useful.
Do not underestimate session recording
Session recording and logging deserve their own evaluation thread. Tracking every privileged activity gives you the audit trail that investigation depends on, and it is how organisations demonstrate compliance with regimes such as HIPAA, PCI DSS and SOX. Ask the awkward questions early: what does recording cost in storage at year three of your retention period, can recordings be tampered with by administrators, and how quickly can an investigator find one session among a million?
PAM deployment models: on-premises vs cloud vs hybrid
There are three deployment models. Each is a different trade-off, not a different quality level.
On-premises
Benefits: control, with total ownership of hardware, data and system configuration; customisation, because the platform can be shaped precisely to unusual requirements; and data sovereignty, because everything stays in-house, which simplifies compliance with local data-residency rules. Disadvantages: maintenance, since upgrades, patching and resilience all land on your IT team; upfront cost in hardware, software and the people to run them; and scalability, because growth means buying and installing more. It remains the traditional choice for heavily regulated industries and operational technology estates where control outweighs convenience.
Cloud
Benefits: scalability, with capacity moving up or down without hardware orders; lower upfront cost, spread as operational rather than capital expenditure; and maintenance handled by the provider, keeping the platform current. Disadvantages: dependence on the provider, whose security, availability and performance become yours; data sovereignty limits, where cloud storage conflicts with strict residency regulation; and customisation, which is usually available but rarely as deep as on-premises. Remember that in the cloud, configuration is the perimeter: several of the largest cloud breaches on record trace back to a settings page, so cloud PAM demands configuration discipline as strict as any firewall rule.
Hybrid
Benefits: flexibility, combining on-premises control with cloud scalability and easier maintenance; data sovereignty, keeping sensitive data in-house while less sensitive workloads run in the cloud; and gradual transition, letting organisations move step by step. Disadvantages: complexity, because you now run both worlds; cost, because you may pay for both footprints; and security, because there are two environments to protect and a seam between them to watch. Hybrid is where most large enterprises land.
Sizing for scale and availability
Whichever model you choose, test the factors demos never cover: system overhead, network load from session streams and credential exchanges, database performance under continuous access-control activity, integration throughput, load balancing across servers or clusters, and high availability through failover and redundancy. A PAM platform is unusual software. If it is down, nobody privileged can work and the security tool becomes the outage. If it is slow, people bypass it. Performance is adoption insurance.
What should a PAM RFI include?
A Request for Information protects the programme. It forces the organisation to write down its requirements before anyone sees a demonstration, builds market intelligence about capabilities you did not know to ask about, pre-selects vendors so later RFPs and RFQs are simpler, strengthens negotiation, sharpens competition because suppliers who know they are being compared bring their best, and doubles as a supplier risk assessment. Against the cost of an unfit platform on a multi-year contract, it is the cheapest insurance a programme will buy.
Fifteen sections make a complete fact-finding document:
- Company overview. Size, years in business, financial stability. You are choosing a partner for a decade.
- Product description. Features, differentiators, and precisely how the product solves your privileged access challenges.
- Deployment models supported. On-premises, cloud, hybrid, and the implications of each.
- Integration capabilities. IAM, SIEM, directory services, cloud platforms and the rest of your estate map.
- Scalability and performance. Documented behaviour under growth and heavy load.
- Security features. How the product manages secure access and how it secures its own stored data.
- Compliance support. For the specific regulations your industry answers to.
- Customer support. Availability, coverage hours and response time commitments.
- Training and documentation. For end users and for administrators.
- Pricing model. The basis of charging, what is included, and the cost of everything that is not.
- Reference customers. Case studies from comparable industries and use cases.
- Product roadmap. Whether the vendor’s direction aligns with your strategy.
- Resilience and high availability. Disaster recovery and business continuity capability.
- Customisation. How far the product bends to your requirements, and what that costs to maintain.
- PAM experience. Depth of expertise in privileged access specifically, not just presence in security.
Treat the RFI as preliminary. It produces a shortlist, which is then tested through detailed evaluation, structured demonstrations and a proof of concept.
How to run a PAM proof of concept that tells you the truth
A proof of concept exists to replace opinion with evidence. Two weeks is a realistic window for a focused PAM PoC, provided the design work happens before it starts.
Design it before you start
- Write success criteria first. Define what pass and fail look like for each scenario, and agree them with the evaluation panel before any vendor has access to the environment.
- Use real systems, real accounts and real engineers. A PoC on a clean lab estate proves the platform works on clean lab estates.
- Include a sceptic. Recruit an experienced administrator who currently relies on a workaround. If they report that the platform is faster than what they do today, that outweighs a hundred feature checkboxes. If they do not, you have learned something before signature rather than after it.
Test the awkward cases
- Onboarding a legacy application and a network device, not only a modern server.
- An emergency break-glass request, timed end to end.
- Credential rotation against a system with embedded or hard-coded credentials.
- Failover and recovery, so you see what happens when a node is lost.
- Session recording retrieval: how long it takes to locate and replay one specific session.
- A representative volume of concurrent sessions rather than a handful.
Score and decide
Record measurements, not impressions: time to complete common tasks compared with the current process, error rates, integration effort in engineer-days, and the number of items that needed vendor professional services. Score against the weighted requirements from the RFI, document the reasoning and keep the evidence. A decision that can still be explained to an auditor or a board two years later is worth as much as the platform itself.
A useful preparatory exercise: split the team into groups, have each research one solution category and present back, then argue the deployment models and brainstorm the integration points. An afternoon of that teaches more about platform selection than a month of vendor material.
PAM integration: IAM, SIEM, directories and the deep estate
Integration is the largest hidden cost in privileged access programmes. A platform touches everything, or it manages nothing. Beyond technical compatibility there is a regulatory layer: the integrated whole still has to meet your security standards and survive an auditor’s verification.
Identity and authentication
- IAM systems. The platform should use existing identity information and policy rules so privileged access rides on the identity lifecycle you already run, with joiner, mover and leaver events flowing through automatically rather than being re-keyed.
- Directory services. Active Directory and LDAP groups should drive privileged access, rather than creating a parallel universe of duplicate accounts.
- MFA. Whatever multi-factor solution the organisation already trusts should wire straight into privileged authentication.
Security operations and service management
- SIEM. Feeding privileged access events into the SIEM lets them be correlated with every other security event, which is the difference between an isolated log entry and a recognised attack pattern. It is the pipe your security operations team will live on.
- ITSM ticketing. Access granted through the platform should trace to an approved ticket, so the paper trail exists by architecture rather than by discipline.
- Cloud services. If the organisation runs AWS, Azure or Google Cloud, the platform must manage access to resources inside them. A solution that stops at the datacentre door manages yesterday’s estate.
The deep estate
- APIs and custom integrations for the in-house applications no vendor has heard of.
- Databases and applications holding sensitive data and embedded credentials.
- Network devices including routers, switches and firewalls.
- Legacy systems, often peripheral yet holding valuable data. Leaving them outside the platform amplifies exposure exactly where visibility is weakest.
- Virtualisation and container platforms, with privileged access managed inside them.
- DevOps tooling and CI/CD pipelines, where machine credentials multiply fastest.
- Encryption and key management, either met by the platform or integrated with the solutions that do.
Price every connector before the contract, not after. Licences are the visible line; connectors, custom scripts and upgrade breakage are the invisible three.
Sofia’s story
Sofia, a Solutions Engineer at Abby Steel, has one habit that shapes the whole selection: immunity to demonstrations. Every platform looks perfect in the vendor’s environment, she tells the programme sponsor, so the only question worth asking is how it behaves in ours. She refuses to shortlist anything until the requirements are written, then builds a Request for Information from them and scores every response against that document rather than against competing marketing claims.
The process ends with proof rather than persuasion. A two-week proof of concept runs on real systems and real accounts, with real engineers, including an administrator who has relied for years on a workaround. His verdict after week one is that the new approach is faster than what he does today and that he will actually use it. That sentence carries more weight than any feature comparison.
Abby Steel selects a hybrid deployment: the operational technology estate stays on-premises behind existing segmentation, corporate IT moves to the cloud, with IAM and SIEM integrated and capacity sized for year five. Architecture follows risk.
Common mistakes to avoid
Shortlisting before writing requirements
Once a team has seen an impressive demonstration, every subsequent requirement is quietly shaped by it. Write and weight the requirements from your own inventory and obligations first, then let vendors respond to them.
Treating the licence as the cost
Connectors, custom scripts for in-house applications, professional services and breakage at each upgrade routinely exceed expectations. Price the integration work during evaluation and make the vendor commit to what is included.
Running the proof of concept on a clean environment
A PoC limited to modern, well-documented servers proves nothing about the estate that actually causes problems. Include legacy systems, network devices, embedded credentials and a failover test, or the first real surprise arrives in production.
Ignoring performance and availability until go-live
If the platform is slow, users build workarounds; if it is down, nobody privileged can work and the security control becomes the outage. Test overhead, database load, load balancing and failover before signature, not after.
Choosing a deployment model on preference rather than risk
Cloud is not automatically modern and on-premises is not automatically safe. Match the model to organisational size, industry, regulatory environment and the team’s genuine capacity to run and patch infrastructure.
Key takeaways
- Requirements first, vendors second: the sequence protects the whole programme.
- There are three deployment models, on-premises, cloud and hybrid, and the right one is the one that matches your risk.
- An RFI costs time up front and is the cheapest insurance against an unfit platform on a multi-year contract.
- A proof of concept on real systems with sceptical engineers is worth more than any feature checklist.
- Integration decides whether a platform manages the estate or only the easy half of it, so price every connector before you sign.
Frequently asked questions
How do I choose a PAM solution?
Start with your own inventory of privileged accounts, systems, use cases and regulatory obligations, and turn it into a weighted requirements set with mandatory and desirable criteria separated. Then run the stages in order: an RFI to build market understanding and a shortlist, an RFP with demonstrations against your scenarios, a proof of concept on your own systems, and commercial negotiation last. Score every vendor against your requirements rather than against competitor comparison material, and compare products within the same solution category so the scoring stays meaningful.
What should a PAM RFI include?
A complete RFI covers fifteen areas: company overview and financial stability, product description, deployment models supported, integration capabilities, scalability and performance, security features, compliance support for your regulations, customer support, training and documentation, pricing model, reference customers in similar industries, product roadmap, resilience and high availability, customisation, and the vendor’s depth of experience in privileged access specifically. Treat the responses as preliminary evidence: the RFI produces the shortlist, and detailed evaluation, demonstrations and a proof of concept produce the decision.
Is cloud or on-premises PAM better?
Neither is better in the abstract. On-premises gives control, deep customisation and data sovereignty, but places maintenance, patching and resilience on your team and requires significant upfront investment. Cloud gives elastic scalability, lower upfront cost and provider-managed upgrades, but creates dependence on the provider’s security and availability, can conflict with data residency rules, and offers less customisation depth. Hybrid combines both and is where most large enterprises land, at the cost of extra complexity, potentially two footprints to pay for, and a seam between environments that needs watching.
How long should a PAM proof of concept take?
Two weeks is a realistic window for a focused PoC, provided the design work is finished before it starts. Write pass and fail criteria for each scenario in advance, use real systems and real accounts, and include experienced administrators who currently rely on workarounds. Test the awkward cases rather than the easy ones: a legacy application, a network device, an emergency break-glass request timed end to end, credential rotation against embedded credentials, failover, and how long it takes to retrieve one recorded session. Record measurements, not impressions.
Why should PAM integrate with a SIEM?
On its own, a privileged access event is an isolated log entry. Fed into a SIEM, it can be correlated with authentication activity, endpoint alerts, network telemetry and threat intelligence, which is what turns a single record into a recognised attack pattern. The integration is also what security operations teams depend on for detection and investigation, and it supports audit and compliance evidence. When evaluating platforms, check the event format, the volume the integration can sustain, and whether session metadata and recordings can be located from a SIEM alert.
Start Module 5 in the PAM Portal
Work through Sofia’s module in full, with the walkthroughs, templates and assessment that turn this into something you can apply on Monday morning.
Open Module 5 in the PAM Portal
Vendor-neutral. Built by practitioners. Designed around the roles that do the work.