Privileged Access Management (PAM): Why Indian Enterprises Are Leaving Their Most Critical Accounts Exposed

• 06 July, 2026
• No Comments

Every network has a skeleton key — a set of accounts with the power to read any file, change any configuration, and silence any alarm. In security, these are called privileged accounts: domain admins, root users, service accounts, firewall management logins, and database superusers. They are the crown jewels of your IT environment, and they are almost certainly underprotected.

For Indian enterprise IT and security leaders, this is not a theoretical problem. Threat intelligence consistently shows that more than 70 percent of breaches involve the misuse of privileged credentials — either stolen through phishing or lateral movement, abused by an insider, or left exposed via misconfigured service accounts that nobody bothered to rotate in years. Under India’s evolving regulatory landscape — the Digital Personal Data Protection (DPDP) Act and CERT-In’s 6-hour breach reporting mandate — failing to govern privileged access is no longer just a security gap; it is a compliance liability.

Privileged Access Management (PAM) is the discipline and toolset that closes this gap. This guide explains what PAM is, why Indian enterprises are uniquely exposed, how to build a practical PAM programme, and how it integrates with the zero-trust and managed security posture that leading organisations are adopting in 2026.

What Is Privileged Access Management?

PAM is a set of cybersecurity controls designed to secure, monitor, and audit all access by accounts that hold elevated permissions. A mature PAM programme typically delivers four capabilities:

• Privileged Account Discovery: Automatically find every privileged account across on-premises systems, cloud workloads, OT environments, and network devices — including forgotten or orphaned accounts.
• Credential Vaulting and Rotation: Store privileged passwords and SSH keys in an encrypted, audited vault. Rotate them automatically on a schedule or after every use, eliminating standing credentials.
• Just-In-Time (JIT) Access: Grant privilege only for the duration of a specific task, then revoke it. An admin who needs to patch a server at 2 AM gets elevated rights for 30 minutes, then returns to a standard account.
• Session Recording and Monitoring: Record every keystroke and screen of privileged sessions, with real-time alerting for suspicious commands (e.g., bulk data exports, shadow copy deletion — a classic ransomware pre-cursor).

Why Indian Enterprises Are Especially Exposed

Several structural factors make Indian organisations disproportionately vulnerable to privileged account abuse:

1. Legacy IT Infrastructure with Sprawling Admin Accounts

Many mid-to-large Indian enterprises have grown through acquisitions or rapid digital expansion over the past decade. The result is a patchwork of on-premises servers, private data centres, SaaS platforms, and now hybrid cloud — each with its own set of local admin accounts. Security teams often lack a complete inventory of privileged accounts, let alone controls over them. Attackers know this; once inside, they move laterally until they find a domain admin or a root account on a critical system.

2. Service Accounts with Excessive Privileges and No Expiry

Service accounts — used by applications, backup tools, monitoring agents, and scheduled jobs — routinely run with domain-admin privileges “because it was easier to set up that way.” These accounts often have passwords that have not changed in years, no MFA, and no session monitoring. They are standing doors left open. In multiple high-profile ransomware cases, attackers have pivoted from a low-level phishing foothold to domain compromise by discovering and abusing a single over-privileged service account.

3. Shared Credentials Among IT Staff

In organisations without a PAM vault, it is common for the entire IT team to share a single “firewall admin” password or a single root SSH key for Linux servers. When a team member leaves, that credential rarely changes. This makes post-incident forensics nearly impossible — you cannot attribute a malicious action to a specific individual when five people shared the same login.

4. DPDP Act and CERT-In Compliance Pressure

The Digital Personal Data Protection Act creates clear accountability for data principals and data fiduciaries. If a privileged account is abused and personal data is exfiltrated, the organisation must demonstrate — to CERT-In within six hours and to the Data Protection Board — that it had appropriate technical and organisational controls in place. Without session logs, credential rotation records, and access governance reports, that demonstration is impossible. PAM is the audit trail that regulators expect.

The Anatomy of a Privileged Account Attack

Understanding the attack chain helps security leaders prioritise where PAM controls matter most:

1. Initial Access: A phishing email delivers a credential-stealing payload to a regular employee. The attacker now owns a low-privilege user account.
2. Reconnaissance: Using that foothold, the attacker runs tools like BloodHound to map Active Directory and find paths to high-value accounts.
3. Lateral Movement: The attacker exploits a misconfigured service account or a poorly secured admin share to escalate privileges.
4. Privilege Escalation: Domain admin credentials are obtained — either from memory via pass-the-hash, from a shared password stored in a script, or by cracking a weak password hash.
5. Impact: With domain admin rights, the attacker disables endpoint protection, exfiltrates data to cloud storage, and deploys ransomware across the environment.

PAM breaks this chain at step 2 (by reducing the attack surface of discoverable privileged accounts), step 3 (by eliminating standing service account credentials), and step 5 (by alerting on anomalous privileged session activity before the payload deploys).

Building a PAM Programme: A Practical Roadmap for Indian Enterprises

A PAM deployment does not need to be a multi-year megaproject. A phased approach delivers security value in weeks, not years.

Phase 1: Discover and Inventory (Weeks 1–4)

• Run an automated discovery scan across Active Directory, local server SAM databases, network devices (FortiGate, switches, routers), cloud IAM, and databases.
• Categorise accounts by type: human admin, service/application, shared, emergency (break-glass).
• Flag accounts with: password age > 90 days, no MFA, domain-admin membership with no recent login, or membership in both privileged and standard groups.
• Produce an asset register. This list alone is often shocking — most organisations discover 3–5× more privileged accounts than they expected.

Phase 2: Vault Critical Credentials (Weeks 4–8)

• Onboard the highest-risk credentials first: domain admins, firewall management accounts, backup admin, database superusers, cloud root/owner accounts.
• Enforce check-out workflows: no human can retrieve a privileged password without logging a reason, their identity, and the target system. The vault rotates the password after check-in.
• Replace embedded plaintext passwords in scripts and configuration files with vault API calls.

Phase 3: Enforce Just-In-Time Access and Session Recording (Weeks 8–16)

• Implement JIT elevation: users request privilege via a self-service portal, a manager or automated policy approves, and access is time-boxed (e.g., 2 hours).
• Route all privileged sessions through a session proxy that records video and keystroke logs, stored in an immutable audit store.
• Configure real-time alerts for dangerous commands: vssadmin delete shadows, net group "domain admins" /add, bcdedit /set recoveryenabled no, and bulk file access anomalies.

Phase 4: Integrate with Zero Trust and SIEM (Ongoing)

• Feed PAM events into your SIEM (FortiSIEM or equivalent) for correlation with network, endpoint, and cloud telemetry.
• Integrate PAM with your ZTNA policy engine: privileged access requests from unrecognised devices or unusual locations should trigger step-up authentication or denial.
• Use PAM analytics to establish behavioural baselines for each admin — unusual login times, new target systems, or new commands become instant alerts.

PAM and FortiGate ZTNA: A Natural Partnership

FortiGate’s ZTNA capabilities and PAM complement each other at the network and identity layers. Where ZTNA ensures that no device or user is trusted by default and enforces continuous verification for every application access request, PAM ensures that no privileged credential is available by default and every elevation is audited.

In a joint deployment, the workflow looks like this: An admin requests access to a critical server. FortiGate ZTNA checks device posture (is the endpoint compliant? Is it running the expected FortiClient version?). Only if posture passes does the ZTNA policy allow the connection to the PAM gateway, where the admin must authenticate again, state a reason for access, and accept that the session will be recorded. This dual-gate architecture means that even if an attacker compromises valid user credentials, they face two independent, policy-enforced checkpoints before reaching a privileged system.

Checklist: PAM Readiness Assessment for Indian Enterprises

Use this checklist to benchmark your current privileged access posture:

• ☐ Complete inventory of all privileged accounts (human + service + shared) exists and is current
• ☐ Privileged passwords are stored in a vault — not spreadsheets, sticky notes, or shared mailboxes
• ☐ Passwords for privileged accounts rotate automatically at least every 90 days (ideally after every use)
• ☐ No service account has domain-admin privileges unless formally risk-accepted and monitored
• ☐ MFA is enforced for all human privileged accounts, with no exceptions for “network admin” or “IT head”
• ☐ All privileged sessions are recorded and logs are retained for at least 12 months (CERT-In requirement)
• ☐ JIT access is in place for at least Tier-0 systems (domain controllers, firewall management, backup infrastructure)
• ☐ PAM events feed into the SOC for real-time alerting
• ☐ A break-glass (emergency) account process exists, is tested quarterly, and is fully audited
• ☐ PAM scope covers cloud IAM, not just on-premises Active Directory

Common PAM Pitfalls to Avoid

Pitfall 1: Treating PAM as a One-Time Project

PAM requires continuous operation: account discovery runs recurring as new systems are added, vault policies must be updated when staff change roles, and session alert rules must evolve as attackers adapt. PAM without ongoing management degrades into a compliance checkbox with no real security value.

Pitfall 2: Ignoring Non-Windows Privileged Accounts

Most PAM programmes start with Active Directory and ignore Linux root accounts, network device management credentials, cloud service principals, and OT system engineering accounts. Attackers don’t ignore them — your PAM scope must not either.

Pitfall 3: Over-Engineering the Approval Workflow

A PAM policy that requires three levels of manager approval to open a firewall change ticket will be circumvented — admins will use break-glass accounts for routine work, undermining the entire programme. Design approval workflows proportionate to risk: routine low-risk tasks with soft guardrails, Tier-0 access with hard controls.

The Cost of Doing Nothing

Consider the consequences when a privileged account is compromised without PAM controls in place. Forensic investigation is impossible without session logs — you cannot reconstruct what the attacker did, which data was accessed, or which systems were modified. Under DPDP Act reporting obligations, this inability to scope a breach means you must assume the worst-case interpretation. Regulatory penalties, reputational damage, and the cost of remediation (which without audit trails often involves rebuilding entire environments from scratch) dwarf the cost of a PAM implementation by orders of magnitude.

For Indian enterprises handling personal data of Indian citizens — which is nearly every enterprise operating in the country — this is not an abstract risk. CERT-In’s 6-hour reporting window means you need answers fast. PAM gives you those answers.

How PJ Networks Helps

PJ Networks offers managed security services built around the principle that privileged access is the highest-value target in any enterprise network. Our team can help you:

• Conduct a PAM Readiness Assessment: We map your entire privileged account landscape across on-premises, cloud, and OT environments, then deliver a prioritised remediation roadmap.
• Design and Deploy PAM Controls: Integrated with your existing FortiGate infrastructure and FortiClient endpoints, our PAM deployments align with your ZTNA policy engine for end-to-end zero-trust enforcement.
• Provide 24/7 Privileged Session Monitoring: Our SOC analysts monitor privileged session activity around the clock, with runbooks tuned to detect the exact command patterns that precede ransomware, data exfiltration, and insider sabotage.
• Support DPDP and CERT-In Compliance: We maintain the session logs, access governance reports, and credential rotation records that regulators require — so when CERT-In asks, you can answer within the hour.

If your organisation cannot confidently answer “yes” to more than seven of the ten checklist items above, your privileged accounts are an open door waiting for the wrong visitor. The question is not whether to implement PAM — it is whether to do it before or after a breach forces the decision.

Contact PJ Networks to schedule a Privileged Access Management readiness workshop. Our security architects work with your team to map the risk, prioritise the controls, and build a PAM programme that integrates seamlessly with your existing FortiGate and Fortinet investment — without disrupting operations.