# PAM concepts > PAM SIM is an independent educational simulator. It is not affiliated with, endorsed by, or derived from any commercial privileged access management product, and it is not a substitute for one. It never connects to a real system, never executes a real command, and never stores a real password. Every account, host, identity and credential named in it is invented. It uses the standard vocabulary of the field because that is the vocabulary a real deployment and a real interview use. ## The stack — where each piece sits *Four products, four different questions, one sentence.* **Industry term:** ZTNA + MFA + authenticator + PAM **In the app:** `/concepts` Expect an opening question about how these fit together, and expect it to be testing whether you see them as competing tools. They are not. Each answers a different question in the same sentence. Zscaler — can you reach it? It brokers the connection. Zero Trust Network Access replaces the VPN: you are granted a path to one specific application, never placed on the network. The multi-factor service — are you really you? It proves the human behind the credential, and raises or lowers friction according to risk signals. The authenticator — how strongly can you prove it? A FIDO2 security key is phishing-resistant in a way a push notification is not, which is why privileged users get one. The privileged access platform — what can you do once you are in? It controls the elevated credential: vaulted, rotated, brokered through a recorded session, never handed to the user. The sentence that ties them together: network access decides whether you reach the system, the factor and the token prove who you are, and privileged access management controls what you can do as an administrator once you are there — with audit evidence produced at every step. Defence in depth, where each layer fails safe. Only the fourth is simulated here. The others are named so you can place them, and because the failure modes cross over: a federation outage stops privileged work while the vault is perfectly healthy. --- ## Why privileged access management exists *Blast-radius containment, not password hygiene.* **Industry term:** PASM / PEDM / secrets / CIEM **In the app:** `/risk` The answer that separates a candidate is being able to walk an attack chain and say which control breaks which link. Initial access, then credential theft, then lateral movement, then privilege escalation, then domain dominance, then persistence. The named techniques worth recognising: pass-the-hash, pass-the-ticket, Kerberoasting, AS-REP roasting, DCSync, golden and silver tickets, NTLM relay, token impersonation, and harvesting credentials from the memory of the local security authority process. They map to the credential-access and lateral-movement tactics in the public adversary catalogue, which is worth saying when it helps rather than as decoration. Where the controls bite: vaulting removes the shared secret people know; rotation makes a stolen credential expire on its own; brokering keeps the secret off the endpoint so it cannot be harvested from memory; session recording makes what happened reconstructable; and just-in-time elevation removes the standing membership that made escalation worth attempting. The taxonomy matters because each class has its own failure mode, and forgetting a class is how estates stay exposed. Local administrator; domain, enterprise and schema admin. Service accounts, and the hardcoded credentials in scripts and configuration. Break-glass and shared accounts. Unix root and sudo. Database privileged accounts. Network device enable accounts. Hypervisor and backup-system accounts — routinely forgotten and effectively Tier 0, because whoever holds the backups holds the data. SSH keys, usually the largest unmanaged population in the estate. API keys, tokens and certificates. Pipeline secrets. Cloud privileged identities and the entitlement sprawl that follows them. And the fact underneath all of it: non-human identity now outnumbers human identity, which is the hardest part of the job rather than a footnote to it. The complete control set a mature programme deploys: vaulting; rotation with verification and reconciliation; enforced uniqueness and complexity; credential injection so no human sees the secret; session proxying, isolation, recording, live monitoring and termination; just-in-time elevation, ephemeral credentials and zero standing privilege; approval workflows, dual control and time-boxed access; endpoint least privilege and application control; discovery and automated onboarding; secrets management for applications and pipelines; threat analytics; and tamper-evident audit trails. One framing to have ready: the analyst-firm split of the market into account and session management, privilege elevation and delegation, secrets management, and cloud entitlement management. Most conversations that call themselves privileged access management are only the first of those four. --- ## Tiering the administrative plane *Credentials that can reach everything must never be typed on machines that browse the internet.* **Industry term:** Tier 0 / Enterprise Access Model / PAW **In the app:** `/vault` The tiered model splits administration by what an identity can control. Tier 0 is anything that controls identity itself — domain controllers, the identity provider, the vault, backup systems, hypervisors. Tier 1 is servers and applications. Tier 2 is user workstations. The rule is that credentials never flow downwards: a Tier 0 credential is never used on a Tier 1 or Tier 2 machine, because typing it there exposes it to whatever has compromised that machine. Microsoft's successor framing is the enterprise access model, which broadens the same idea to control planes, management planes and data planes across cloud and on-premises, rather than three server tiers. Know both names; the principle did not change. The practical expression is a privileged access workstation: a hardened, single-purpose machine used only for administration, with no email and no general web browsing, which is where Tier 0 work actually happens. A jump or bastion host does a related job for a specific target estate. The session gateway is a jump host with the credential handling and recording built in. The earlier design with a separate hardened forest — the red forest — is retired, and knowing why is a small credibility marker: it protected identity administration well and did nothing for the cloud control plane, which is now where the crown jewels sit. It gets asked because it distinguishes people who learned this recently from people who learned it once. The vault is itself Tier 0. That is not a slogan: it drives hardening, high availability, a disaster recovery replica and a recovery path you have actually tested — and it is why the credentials that recover the platform cannot depend on the platform. --- ## Authenticators — and why the form factor is not the point *Phishing resistance is the dividing line, not whether you can hold it.* **Industry term:** FIDO2 / WebAuthn / OTP tokens / PIV **In the app:** `/concepts` The instinct that hardware is automatically strongest is wrong, and saying so is the answer. A security key implementing the modern web authentication standard is phishing-resistant. A one-time-password fob is hardware and still phishable, because a relay can capture and replay the code inside its validity window. What makes a key resistant is not the plastic: the private key never leaves the device, and the credential is bound to the origin, so it will not sign for a lookalike domain. A user pushed to a convincing replica simply cannot complete the ceremony. User verification by PIN or biometric adds the second factor, and discoverable credentials enable passwordless sign-in entirely. One-time-password hardware — the classic fob, and the open-standard time-based and counter-based tokens — shares a seed at manufacture and displays a rotating code. Stronger than a code sent by message, and still phishable. The operational details that come up: clock drift, next-tokencode mode, and a passcode formed from a PIN plus the displayed code. Certificate-based smart cards sit behind a public-key infrastructure: the card holds the private key and a PIN unlocks it. Common in government and heavily regulated estates, and they bring a whole certificate lifecycle with them — issuance, renewal, revocation, and a certificate authority that is itself Tier 0. Multi-protocol devices are why one key can cover a mixed estate: the same device can act as a modern web authenticator, a smart card, a time-based token and a code generator at once. That flexibility is what makes them practical for privileged users who still meet legacy systems. The lifecycle is the hard part, and it is where audit findings come from. Procurement and inventory, enrolment to a named user, distribution with a chain of custody, replacement for lost or broken devices, revocation on loss, and return on termination. An unreturned token from a leaver is a finding; an untracked spare is worse. Every deployment needs an answer to "I left it at home", and that answer is the control most likely to decay into a routine workaround. Verify identity out of band before issuing anything — the lost-token call is a social-engineering target, so that step is a control, not paperwork. Prefer a second registered key to a bypass code. If a code is issued, make it single-use and short-lived, alert on issue and use, and review who is using them and how often. Policy in practice: hardware for privileged and high-risk populations, software authenticators for everyone else. The federal assurance framework's highest authenticator level effectively requires hardware, which is the standards-based way to justify the cost. --- ## Zero trust network access, precisely *Two different products with opposite directions, and people call both of them "the VPN".* **Industry term:** ZTNA / SASE / SSE **In the app:** `/concepts` Be precise, because the imprecision is itself the filter. The private-access product is a zero-trust replacement for the VPN. The internet-access product is a cloud secure web gateway. They are licensed, configured and logged separately, and they point in opposite directions. Private access replaces the VPN. Connectors sit beside the application and make outbound connections to the cloud service; when a user requests the application, the broker stitches the user's outbound connection to the connector's outbound connection in the middle. There is no listening port on the application side, no inbound firewall rule, and nothing internet-facing to scan. Users are brokered to one specific application and never placed on a network — which removes by design the lateral movement a VPN grants by design. Internet access is the outbound half: URL filtering, encrypted-traffic inspection, cloud firewall, sandboxing, cloud application visibility and data loss prevention. Traffic reaches it through an endpoint agent, proxy configuration files, or tunnels from branch offices. The architecture pieces worth naming: the endpoint agent, the connectors deployed beside private applications, the enforcement nodes in the cloud where policy is applied, and the central authority that distributes configuration and policy. Inspecting encrypted traffic is necessary because that is how threats arrive, and it is consequential: it needs a trusted root certificate on every endpoint and bypass lists for banking, healthcare and certificate-pinned applications. Privacy, legal and works-council considerations are part of the answer rather than an afterthought — saying so is what makes the answer sound like it came from a deployment. Identity and posture converge here. Authentication federates to the identity provider, users and groups synchronise by the provisioning standard, and device posture — patch level, disk encryption, an endpoint detection agent, a certificate, domain membership — gates access. Posture is a point-in-time attestation from the endpoint, so it complements controls on the target rather than replacing them. The logs are evidence: who reached which application, when, from what device, streamed into the enterprise security monitoring platform. Two acronyms that appear constantly in job descriptions: the convergence of networking and security delivered from the cloud, and the security half of that convergence on its own — the secure web gateway, cloud application broker, zero-trust access and data loss prevention pieces. How it combines with privileged access: network access decides whether you can reach the administrative plane at all, per application, with identity and posture as inputs, exposing nothing inbound — so it shrinks blast radius before privilege is involved. Privileged access decides what you can do once there. Layered, stolen credentials alone do not get an attacker to the jump host; they also need an enrolled identity and a device that passes posture. --- ## Running the platform — upgrades, resilience and cost *The half of the job that is not access engineering, and where the awkward questions live.* **Industry term:** DR / upgrade order / licensing **In the app:** `/vault` Resilience first, because privileged access is a Tier 0 availability dependency. A disaster recovery vault replicating from the primary, distributed or satellite vaults where an estate is geographically split, and load-balanced portal, credential manager and session manager components. Backup and restore have their own dedicated utilities rather than being a file copy, because the encrypted store is not something you back up by copying the directory. Expect the follow-up question, and expect it to be the real one: have you actually tested a failover, or only documented one? A replica nobody has promoted is a belief. The honest answer names when you last tested and what broke. Upgrades have an order and it matters: the vault first, then the portal, then the credential manager, then the session managers, with version compatibility checked across components. In-place against side-by-side is a risk decision rather than a preference. And always re-validate a rotation and a live brokered session afterwards — an upgrade that leaves credential management silently failing is worse than no upgrade, because nothing alerts and the failure surfaces months later as an audit finding. Where to look when it breaks, by component: the credential manager's console and trace logs for rotation failures; the session manager's logs for connection component errors; the portal's logs for interface and API problems; the vault trace for authentication and permission problems. Most failures are environmental rather than product defects, and saying that unprompted signals experience. The common failure modes, in the order you meet them: the credential manager cannot rotate, because of drift, reconcile-account permissions, connectivity or platform misconfiguration; session connection components erroring; discovery missing accounts; replication falling behind; and service dependencies breaking after a rotation. Licensing is licensed per managed account, which is why "onboard everything" meets budget resistance and why prioritising by risk — Tier 0 first — is simultaneously good security and good politics. Being able to say that out loud is a sign you have argued for a budget rather than only consumed one. Deployment model: self-hosted keeps control of upgrade timing, network placement and data residency, which regulated banks often want and sometimes need. The hosted model removes the infrastructure, availability and upgrade burden, which is real capacity returned to access engineering. Have a view and be able to justify it, and say what would change your mind. --- ## Maturity and the numbers that prove it *How to frame a roadmap answer, and what to quantify when you do.* **Industry term:** PAM maturity model / programme metrics **In the app:** `/reports` The arc, which is the frame for any "where would you take this?" question: ad hoc, then discovered and inventoried, then vaulted, then rotated, then session-controlled, then least privilege enforced, then just-in-time with zero standing privilege, then analytics and identity threat detection driven. The value of the arc is that it forces the order. You cannot secure an estate you have not inventoried; you should not attempt session control before the credential is vaulted and rotating; and zero standing privilege is meaningless while nobody knows what standing privilege exists. The numbers to quantify with. Coverage: the percentage of the known privileged estate actually under management, and discovery coverage against the estimated estate. Hygiene: rotation compliance, credential age, and the failed-rotation backlog. Control: the percentage of privileged sessions isolated and recorded. Direction of travel: standing-privilege reduction and just-in-time adoption. Operations: time to onboard an account, break-glass usage count and review rate. Lifecycle: orphaned or stale privileged accounts eliminated, and deprovisioning time for leavers. Authentication: multi-factor coverage on administrative access, and specifically the share on phishing-resistant factors. Hardware: tokens issued, returned on termination, and unreturned — an audit-visible number. Compliance: access-review completion rate, and control gaps closed. The first metric is the most diagnostic, and it works as a question to ask them as well as an answer to give: what percentage of the privileged estate is under management? If there is no number, that is the number — no denominator means no discovery, and the first six months of the job are an inventory exercise. --- ## The standards behind the requirements *Which document a control actually comes from, and which ones a bank examiner works from.* **Industry term:** NIST / CIS / ISO / PCI DSS / FFIEC **In the app:** `/concepts` The federal control catalogue is the vocabulary most control language borrows from: account management, segregation of duties, least privilege, remote access, and the whole audit and accountability family. When somebody asks why a control exists, this is where the requirement is written down. The digital identity guidelines split assurance into three dimensions — how strongly the identity was proofed, how strongly the authenticator proves possession, and how strongly a federated assertion is protected. The top authenticator level effectively requires hardware, which is the standards-based justification for buying keys. The zero trust architecture publication is the model behind network access that refuses to trust anything because of where it sits on the network. The internet security benchmarks contribute two directly relevant controls — account management and access control management — plus the hardening baselines you are measured against. The international management standard contributes its access-control clauses. The card-data standard's requirements seven and eight cover restricting access by business need and identifying and authenticating every user, including multi-factor for all administrative access and the rule that shared accounts must be individually attributable. For a bank specifically: the financial privacy legislation's safeguards reach banks through interagency guidelines enforced by the banking agencies rather than through the trade regulator's rule — a distinction worth getting right. The examination council publishes the handbook examiners actually work from. The national bank supervisor sets heightened standards for large institutions. And the financial reporting legislation is what makes access to programs and data an audited domain rather than a preference. On the data side, the requirements that touch access decisions: classification, loss prevention, encryption at rest and in transit, key management, data access governance, and the privacy regimes where they drive who may see what. --- ## The wider landscape *Do not be a one-vendor candidate.* **Industry term:** Market landscape **In the app:** `/concepts` Naming the alternatives shows you understand the category rather than one product's menu, and it is a normal interview question because most estates have more than one of these. Privileged access: the main platform this simulator models, plus the other established vendors in the space, each with a password-store product and an endpoint-privilege product. Their existence matters because you will meet them in an acquisition. Secrets and infrastructure access: the general-purpose secrets managers and the modern infrastructure-access products that broker SSH, Kubernetes and database sessions with short-lived certificates rather than stored passwords. Increasingly the answer for engineering estates. Multi-factor and identity: the federation and multi-factor vendors, and the large cloud identity providers whose own privileged identity management does time-bound role activation natively. Zero trust and the security service edge: the network-access vendors whose products replace the VPN and inspect outbound traffic. Cloud-native privilege: the cloud providers' own secret stores and identity centres, plus just-in-time role activation. This is where the model shifts from an account with a password to a role that can be assumed, and from rotation to eliminating persistent access altogether. The useful sentence: the fundamentals survive the vendor. Discover, apply least privilege, remove standing access, broker and record, produce evidence. The product decides how, not what. --- ## The federation and multi-factor portfolio *The multi-factor service is one product in a stack you should be able to name.* **Industry term:** PingID / PingFederate **In the app:** `/concepts` Banks often favour this vendor because its federation server can run on-premises and hybrid, unlike pure cloud-only identity platforms — which matters when data residency and examiner expectations constrain where authentication happens. The pieces: the multi-factor service; the federation server that speaks the assertion, connect and delegated-authorisation protocols and acts as an authorisation server; the cloud platform; the web access management and reverse proxy product; the directory; the fine-grained authorisation product; and the identity orchestration tool. The federation server is the component most likely to sit in the login path of everything, which makes its availability design a first-order concern rather than a detail. Its concepts worth knowing: identity-provider and service-provider connections, adapters for form, Kerberos and composite authentication, token translation between protocols, attribute mapping and policy contracts, and clustering. Authentication methods, roughly in order of strength: security keys and platform biometrics first, because they are origin-bound; then push with number matching; then time-based codes in an application; then codes by email; with message and voice delivery last, because of subscriber-identity swapping and interception. Desktop login for both major operating systems, and offline one-time codes for the no-network case. Where it integrates: network devices and VPN concentrators through the legacy remote-authentication protocol, desktop login, SSH, third-party single sign-on, and custom applications through the software development kit. That legacy protocol is the standard answer to how multi-factor gets in front of infrastructure that cannot speak modern federation. Policies evaluate signals — impossible travel, address reputation, a new device, network zone, device posture — and step challenges up or waive them, so friction is proportional to risk. For privileged identities, set a floor rather than letting a low score waive the challenge. The operational reality is device lifecycle: pairing and enrolment, device management, lost and replaced phones, temporary bypass codes and re-enrolment. Bypass codes are the soft underbelly — a legitimate necessity and a standing risk. --- ## What is a Vault? *The hardened, encrypted store that holds every privileged credential.* **Industry term:** Credential vault / Enterprise Password Vault (EPV) **In the app:** `/vault` The Vault is the secure repository at the centre of a PAM deployment. Privileged passwords, SSH keys and secrets are encrypted and stored here instead of living in scripts, spreadsheets, password managers or people's heads. A vault is built around a layered key hierarchy: each stored object is encrypted with its own key, those keys are protected by a safe key, and the safe keys are protected by a server key that is held outside the database. Losing the database alone therefore yields nothing usable. Critically, the Vault is not just storage — it is a policy enforcement point. Nothing enters or leaves without an authenticated identity, an authorisation check against the safe, and an audit record. That is what separates a vault from a database with a password column. --- ## What is a Safe? *A logical container that groups privileged accounts and controls who may use them.* **Industry term:** Safe **In the app:** `/safes` A safe is the unit of authorisation inside the Vault. Accounts are placed into safes, and permissions are granted on the safe rather than on individual accounts — so access control scales with the number of teams, not the number of credentials. A well-designed safe maps to a single scope of duty: one team, one environment, one class of system. 'Windows Servers — Production' is a good safe. 'All Passwords' is not, because every permission grant on it is automatically over-broad. Membership is granular. A user may be allowed to retrieve credentials (Use), administer the accounts inside (Manage), authorise other people's requests (Approve), or only read the history (Audit). Least privilege is expressed here. --- ## What is a privileged account? *Any identity whose credentials grant elevated control over a system, application or cloud tenant.* **Industry term:** Account **In the app:** `/accounts` A privileged account is one that can change the state of a system rather than merely use it: domain administrators, local administrators, root, service accounts, database owners, network device enable accounts, cloud tenant administrators and break glass accounts. In PAM terms an 'account' is the combination of a username, a target address, and the platform that describes how the credential is to be managed. The same username on two different servers is two accounts, because each has its own credential lifecycle. Privileged accounts are attractive to attackers precisely because they are shared, long-lived and often unmonitored. Vaulting them replaces all three properties: the credential becomes unknown to humans, short-lived, and used only through an audited path. --- ## What is the PVWA? *The web portal where users search for privileged accounts, request access and launch sessions.* **Industry term:** PVWA (Password Vault Web Access) **In the app:** `/portal` The Password Vault Web Access is the primary human interface to the Vault. Users do not connect to target systems directly and they do not learn passwords — they come to the portal, find the account they need, justify why they need it, and receive time-limited access. The portal is also where administrators onboard accounts, define safes and platforms, and review compliance. In the modern platform this experience has been folded into a single unified portal alongside the other identity security services. The design principle is that the portal is the only front door. If a user can reach a privileged credential any other way, every control behind the portal — approval, recording, rotation, audit — is optional in practice. --- ## What is the CPM? *The engine that automatically changes, verifies and reconciles privileged credentials.* **Industry term:** CPM (Central Policy Manager) **In the app:** `/cpm` The Central Policy Manager enforces credential policy without human involvement. On a schedule set by the platform it connects to each target, changes the password to a new random value that satisfies the complexity rules, verifies that the new value works, and writes it back into the Vault. Three job types matter. Change replaces the password. Verify confirms the stored password still authenticates against the target — this is how drift is detected. Reconcile uses a separate, highly privileged reconciliation account to forcibly reset a credential that has drifted out of sync. Automatic rotation is what makes a compromised credential expire on its own. It also means no human ever needs to know the password, which in turn is what makes session brokering and full auditability possible. --- ## What is the PSM? *A controlled gateway that brokers privileged sessions so they can be isolated, monitored and recorded.* **Industry term:** PSM (Privileged Session Manager) **In the app:** `/sessions` The Privileged Session Manager sits between the user and the target system. The user's client connects to the PSM; the PSM retrieves the credential from the Vault and opens the real connection to the target. The credential is injected, never revealed. Because every session passes through the gateway, three things become possible: isolation (malware on the user's endpoint never touches the target directly), monitoring (an administrator can watch, suspend or terminate a live session), and recording (a replayable, searchable record of everything that was done). This is also where risk detection happens. Commands and window activity are scored as they occur, so a session that starts as routine maintenance and turns into credential dumping raises an alert while it is still running. --- ## What is the PSMP, and how does it differ from the PSM? *The same brokering idea for SSH, done as a proxy so the native client still works.* **Industry term:** PSMP / PSM for SSH **In the app:** `/platforms` The Privileged Session Manager for SSH — usually written PSMP — brokers SSH, SCP, SFTP and Rsync. It exists because the Windows-oriented PSM model does not fit how engineers actually work on Unix: forcing them through a Windows jump host to reach a Linux box is friction they will route around. The difference is the shape, not the principle. The PSM is a jump server: your RDP client connects to it, and it runs the session on your behalf on a Windows host. The PSMP is a transparent proxy: you use your normal ssh client, with a connection string like ssh alice@root#linux-prod-01@psmp.corp, and the proxy authenticates you, fetches the credential from the vault, opens the real session and records it. Nothing is installed on the target. Consequences worth knowing. PSMP runs on Linux and PSM on Windows, so they are separately deployed, separately hardened and separately capacity-planned. PSMP supports SSH key authentication as well as passwords. And because it keeps the native client, it is what makes 'no direct SSH to production' an enforceable rule rather than a policy nobody follows. In an interview the trap is treating them as one product with two names. They are two components, and the tell is the port: 3389 for RDP through the PSM, 22 for SSH through the PSMP. --- ## How do applications get privileged credentials? *They ask a provider at runtime, and the provider authenticates the application itself.* **Industry term:** AAM / Credential Provider / CCP **In the app:** `/applications` Everything else in a PAM platform assumes a human who can be shown a portal and asked to justify themselves. Applications cannot do that, and they need privileged credentials constantly — a database password, an API key, a service account for a scheduled task. Left alone, those end up in config files, deployment scripts and source control, where they never rotate because rotating them breaks something. The credential provider inverts it. Nothing is stored in the application: it asks for the secret when it needs it, and the provider authenticates the *application* by its own properties — the host it runs on, the OS account it runs as, the path and cryptographic hash of its executable, or a client certificate. Because the application holds nothing, the credential is finally free to rotate. Two deployment shapes. The Credential Provider is an agent on the application server: the call is local, it can inspect the calling process directly, and it caches so a retrieval survives a network outage. The Central Credential Provider is agentless — an HTTPS call to a REST endpoint — which is the only option for containers, appliances and hosts rebuilt from an image, at the cost of a network dependency and weaker identity, since there is no local process to inspect. The failure worth knowing: an application identified only by its network address. Anything else running on that host presents the same address, so the credential is protected by nothing more than a foothold on the server. Taking a password out of a config file and stopping there is half a remediation, and it is extremely common. --- ## Where does PAM sit inside IAM? *One of three pillars — governance, access management and privileged access.* **Industry term:** IAM / IGA / AM / PAM **In the app:** `/concepts` PAM is a subset of IAM, not a synonym for it, and at a bank each pillar is usually a separate team with its own tooling and its own manager. IGA — Identity Governance and Administration — owns the lifecycle. Joiners, movers and leavers; provisioning and deprovisioning; access review campaigns and recertification; segregation-of-duties rules. It answers whether an identity should have access at all, and asks again every quarter. AM — Access Management — owns authentication for ordinary users. Single sign-on, multi-factor, federation over SAML and OIDC, adaptive or risk-based access, session management. It answers whether you are who you say you are. PAM owns privileged credentials: vaulting, rotation, session brokering, recording. It answers what you may do once you hold elevated rights, and makes it reconstructable afterwards. They are not independent. You reach the privileged portal through AM, so an MFA or federation outage stops privileged work while the vault is perfectly healthy — a real incident pattern that catches people out. And IGA's leaver process is what should remove safe membership; when it fails, the orphaned privileged access is what makes the failure visible. --- ## What is a secrets manager, and how is it different from a vault? *Identity comes from the platform, and many secrets are minted on demand and expire.* **Industry term:** Conjur / Secrets Manager / Secretless **In the app:** `/secrets` The vault model assumes a credential that exists between uses: it is stored, it is rotated, and the control is how often you change it. That is right for a domain administrator account and a network switch, and it fits badly around containers and pipelines, which appear and disappear faster than any rotation schedule. A secrets manager changes two things. Identity is borrowed from the platform the workload already runs on — Kubernetes signs a service-account token, AWS confirms which role signed a request, an OIDC provider signs a token for a specific pipeline run. Nobody has to place a bootstrap credential on the host, which is the circular problem that defeats the naive approach. The second change is dynamic secrets. Instead of storing a value and rotating it, the manager mints one when it is asked for — a short-lived STS credential, a database user created with the right grants and dropped afterwards — with a time to live. Nothing exists before the request and nothing persists after the lease, so there is no rotation to schedule, no standing credential to steal, and a leaked build log is worthless by the time anyone reads it. The unit of management is the lease, and the containment action is to revoke it. It does not replace the vault, and saying so is part of the answer. A target has to support minting and destroying credentials for a dynamic secret to be possible; a mainframe cannot. Real estates run both and synchronise the static secrets between them so one credential has one source of truth. Access is defined as policy in version control rather than clicked together, which is what makes 'who can read this secret' a question you answer with grep. --- ## What is PTA? *The analytics layer that decides which privileged activity is worth waking someone for.* **Industry term:** PTA (Privileged Threat Analytics) / Identity Security Intelligence **In the app:** `/alerts` Privileged Threat Analytics watches privileged activity and raises named detections. The audit trail records everything that happened; PTA is the judgement about which of it matters. Without that layer a bank generates millions of privileged events a month and reviews none of them meaningfully. It draws on three sources at once, which is what lets it see things no single source can. From the vault it knows every legitimate credential retrieval and rotation. From the session gateway it knows what was typed and run. From directory and network telemetry it knows what authenticated where. A privileged logon on a domain controller that has *no* matching vault retrieval is the classic finding: someone used a credential the vault did not hand out. The detections are a finite list rather than a vague notion of 'anomaly' — suspected credential theft, PSM bypass, golden ticket, over-pass-the-hash, unmanaged privileged account, irregular hours, irregular source, excessive access. Each carries a remediation, and the important ones can be automatic: on suspected theft the platform can rotate the credential immediately, which invalidates what the attacker took while the investigation is still being opened. Know where it sits relative to the SIEM. PTA is privileged-specific and understands vault context; the SIEM is enterprise-wide and does not. In practice PTA detects and the SIEM correlates — PTA findings are forwarded there so a privileged detection can be joined to endpoint and network evidence. --- ## What is a Platform? *The policy template that defines how a class of accounts is managed.* **Industry term:** Platform **In the app:** `/platforms` A platform answers the operational questions for a whole class of accounts at once: how long may the password live, how complex must it be, how do we connect to change it, do we verify, do we auto-reconcile on failure, is dual control required, must sessions be recorded, how long may a session run. Accounts inherit their behaviour from their platform. Change the change interval on the Windows Domain Account platform and every account using it is re-evaluated for compliance — this is why platforms, not accounts, are the right place to express policy. Platforms also encode the connection mechanics: which connection component drives an RDP session, whether SSH uses a key or a password, which SQL driver reaches the database. That is the part that makes a policy actually executable. --- ## How does privileged access approval work? *Dual control: a second person must authorise before privilege can be used, and only for a fixed window.* **Industry term:** Dual control / access workflow **In the app:** `/requests/incoming` The requester selects an account, states a business justification, optionally references a ticket, and asks for a specific time window. Nothing is granted yet — the request sits in the approver's Incoming Requests queue. The approver reviews the justification against the sensitivity of the account and the requester's role, then confirms or rejects with a comment. Approval creates a grant with a hard expiry; when the window elapses the grant dies on its own without anyone remembering to revoke it. This is the mechanism underneath just-in-time access and Zero Standing Privileges. The user holds no privilege at rest; they acquire it for the duration of a task and lose it automatically. Every step — request, decision, use, expiry — is audited. --- ## How does session recording work? *Everything done in a brokered session is captured as a replayable, scored timeline.* **Industry term:** PSM recording **In the app:** `/recordings` Because the session gateway sits in the middle of the connection, it can capture the session as it happens: commands typed in a shell, window titles opened in a desktop session, SQL statements issued against a database. The result is a timeline rather than a video file alone — individual activities are indexed, searchable, and scored for risk, so a reviewer can jump straight to the interesting moment instead of watching an hour of idle desktop. Recording serves two purposes: deterrence (people behave differently when the session is on the record) and forensics (after an incident you can reconstruct exactly what a privileged identity did, and prove what it did not do). --- ## How does RBAC work here? *Permissions attach to roles; roles attach to users; safes add a second, resource-scoped layer.* **Industry term:** Roles, safe permissions **In the app:** `/roles` PAM SIM uses two complementary layers. The role determines what kind of thing you may do at all — retrieve credentials, approve requests, manage platforms, read audit. Safe membership determines which resources you may do it to. An Auditor can read every audit event and every recording but cannot retrieve a single credential. A Standard User can search accounts and raise requests but cannot approve their own. A PAM Administrator manages safes, accounts, platforms and rotation but is deliberately not an approver by default. That separation is the point: the person who can grant access, the person who can use access, and the person who can review access should not be the same person. Try switching identity in the header — the navigation and the buttons change with your permissions, not just the error messages. --- ## How does auditing work? *Every meaningful action writes an immutable, attributable event.* **Industry term:** Audit / Identity Security Intelligence **In the app:** `/audit` An audit event records timestamp, actor, action, resource, source IP, result and risk. Read-only actions count: retrieving a credential is one of the most important events in the log, because it is the moment a human gained the ability to act as a privileged identity. Attribution is what PAM adds over native system logs. A target system only ever sees 'Administrator logged in'. The vault knows which human borrowed that identity, under which approval, for which stated reason. Good audit is complete and boring — it is not an alerting system. Security events and risk scoring sit on top of the audit trail to pick out what deserves attention; the trail itself is designed to be exhaustive. --- ## What is break glass access? *The credential of last resort, wrapped in heavy compensating controls.* **Industry term:** Break glass / emergency access **In the app:** `/portal` Break glass accounts exist for the day the normal path fails — the identity provider is down, the approval chain is unreachable, or a domain-wide outage has locked everyone out. They are deliberately powerful and deliberately uncomfortable to use. The controls around them are compensating rather than preventive: mandatory emergency justification, expedited but still-required authorisation, unconditional session recording, a critical security alert the moment they are touched, and automatic credential rotation as soon as the session ends. The rotation is the part people forget. Without it, an emergency password becomes a shared standing credential that a handful of people now know — which is exactly the risk the whole PAM programme was built to remove. --- ## How is risk scored? *An additive, explainable model: privilege + password age + usage + anomaly + violations.* **Industry term:** Risk scoring / Identity Security Intelligence **In the app:** `/risk` PAM SIM scores each account out of 100 by adding named factors. Base privilege reflects what the account can do (a domain administrator outranks a read-only service account). Password age is measured against the platform's change interval, so 'old' is relative to policy rather than absolute. Access frequency, session anomalies (high-risk activity observed in recorded sessions) and outstanding policy violations add the rest. Every contributing factor is shown on the account with its point value and the reason it applied. Explainability is the design goal. A risk score nobody can decompose is a number nobody acts on — the useful question is never 'is this 82 or 74?' but 'which of these five things do I fix first?' --- ## What are Zero Standing Privileges? *Nobody holds privilege at rest; it is granted for a task and removed automatically.* **Industry term:** Zero Standing Privileges (ZSP) / JIT access **In the app:** `/portal` Standing privilege is an account that is permanently a member of an administrative group. It is convenient and it is the single largest source of lateral-movement risk, because compromising the user compromises the privilege permanently. Zero Standing Privileges inverts the default: the user is ordinary until an approved, time-bound grant elevates them, and they return to ordinary automatically. The modern shorthand for the three variables involved is TEA — Time, Entitlements, Approvals. Vaulting a shared credential is the first step towards this, brokering the session is the second, and time-limited approval is the third. PAM SIM's request workflow demonstrates all three together. --- ## Safe, platform or Master Policy — where does a rule live? *Three layers: who may touch it, how it is managed, and the rules that sit above both.* **Industry term:** Safe / Platform / Master Policy **In the app:** `/policies` This is one of the most reliable interview questions, because the answer separates people who have administered a vault from people who have read the datasheet. Three objects, three different questions. A safe answers who may touch this credential. It is the authorisation boundary: membership decides who can list, use, retrieve, add, manage or approve. If two teams need different access to the same kind of system, that is a safe problem. A platform answers how this credential is maintained. It is the technical policy for a class of account: rotation interval, password complexity, verification, reconciliation, which connection components may be used, how the plugin talks to that target type. If two accounts sit in the same business area but one is a Windows domain account and the other an Oracle database account, they need different platforms and can share a safe. The Master Policy sits above both, holding organisation-wide rules: require dual control, enforce exclusive access, one-time passwords, demand a reason or a ticket, mandate session recording. Exceptions are granted per platform. So the question 'how do you make this one system stricter?' is a Master Policy exception on its platform. A new safe would change who can reach it, which is a different question — and saying that distinction out loud is the answer. --- ## How is a privileged access platform automated? *A REST interface behind the portal — and the status code tells you which layer failed.* **Industry term:** PVWA REST API **In the app:** `/rest-api` Everything done by hand in the portal is available programmatically: creating accounts, safes and members, triggering rotations, pulling evidence. That is what makes onboarding at scale possible, and what makes a scheduled quarterly access review an extract rather than three days of clicking. The sequence is always the same shape. Authenticate and receive a session token, send that token in the Authorization header on every call, check the status code and the response body, log off. A script that authenticates in a loop and never logs off exhausts the session limit, and the resulting failure looks like an outage. The status codes are where the interview questions live, because each one sends you somewhere different. 400 the request was malformed. 401 you never got in. 403 you got in and are not allowed. 404 it does not exist, or exists and is invisible to you. 409 the state refuses it, usually a duplicate. 429 you are being throttled. 5xx the server failed and nothing you send will fix it. 401 against 403 is the one that gets asked. Troubleshooting safe permissions on a 401 wastes the first twenty minutes; regenerating a token on a 403 achieves nothing, because the token was never the problem. The worse habit is the usual fix for a repeated 403 — granting the automation identity administrative rights, which converts a permissions question into a standing privileged account with its credential in a config file. What makes automation safe rather than clever: a dedicated identity per integration so activity is attributable, the minimum permissions the workflow needs, the script fetching its own credential at runtime, re-runnability so a partial failure can be repeated, backoff on 429, a dry-run mode, a rollback path, and never writing a token or a secret into a log. --- ## Why read the target's event log as well as the vault's? *Two records of the same event, and the finding is usually in the gap between them.* **Industry term:** Windows Security log / event forwarding **In the app:** `/target-events` A Windows server has no idea that privileged access management exists. It records that DOMAIN\Administrator logged on from an address at a time. It does not know which human borrowed that identity, under what approval, for what stated reason — the vault holds that half, and neither log is complete on its own. The events worth knowing by heart are small in number. 4624 a logon succeeded, with the account, source address and logon type. 4625 a logon failed, with a status code saying why. 4672 that logon holds special privileges — the event that marks a session as administrative, and the efficient filter when you want privileged activity rather than all activity. Then 4740 a lockout, 4724 a password reset by somebody else, 4728 a group membership change, 1102 the log was cleared. Correlation is the actual skill. A 4624 with a matching vault retrieval is routine privileged work. A 4624 with no matching retrieval is a credential the vault never handed out — either obtained outside the platform, or reached by a network path that bypasses the session manager. That finding does not exist in either log alone, and it is the headline detection in privileged threat analytics for exactly that reason. The same logic runs the other way. A repeating 4625 from one host after a rotation is the stale dependency nobody mapped — a service, a scheduled task or an application pool still authenticating with the old password. A 4740 names the caller computer in the event, which is what you must fix before reconciling, or the lockout cycle simply restarts. The sentence that finishes the answer: an event ID is only evidence if the audit policy producing it was enabled, the log was large enough not to have wrapped, and the events were forwarded somewhere they survive the host. Before saying something did not happen, confirm you would have seen it if it had. --- ## How do the components interact? *The portal brokers people, the CPM manages credentials, the gateway brokers connections, the Vault holds truth.* **Industry term:** Vault + PVWA + CPM + PSM **In the app:** `/concepts` A user authenticates to the portal and asks for an account. The portal checks role permissions and safe membership, and if policy requires it, routes the request to an approver. Once authorised, the session gateway asks the Vault for the credential, injects it into a connection to the target, and records everything that follows. The user never sees the password. When the session ends, the credential manager may rotate the credential immediately, so the value that was briefly in memory becomes worthless. Every step in that chain writes to the audit trail, and the risk engine reads the trail back to score accounts, sessions and users.