From Endpoint PAM to Cloud-Native JIT: Securing Azure Infrastructure and Databases for a Global Manufacturing Conglomerate

Customer Snapshot

Attribute	Details
Industry	Manufacturing, Infrastructure, and Consumer Goods (Global Conglomerate)
Cloud Environment	Azure (3 subscriptions) + On-premises
Workloads	Virtual Machines (~10 in this division, 150+ across the group)
Databases	MySQL (primary), PostgreSQL, MongoDB (4 databases supporting a new AI platform)
IAM / PAM	Microsoft Intune (endpoint-focused), EntraID for Azure identity
Users with Cloud Access	5–7 people
Users with Database Access	2 people
Code & CI/CD	GitHub, Jenkins
Collaboration	Microsoft Teams
Compliance Requirements	SOC 2 and GDPR
Primary Interest	JIT Access, Database Activity Monitoring, Compliance Automation

The Situation: A Manufacturing Giant Going Digital, with Security That Has Not Kept Pace

This is a division within a major global conglomerate; one of the largest players in manufacturing, infrastructure, and consumer goods. Their physical operations span continents. Their digital transformation is accelerating.

The most visible marker of that transformation: a new AI-powered interview platform (running on 9 servers with 4 databases) that is live in production and growing. Behind it sits a hybrid infrastructure, on-premises systems that have served the manufacturing core for decades, and Azure cloud that is increasingly where new workloads land.

The security team is small. Five to seven people have access to the cloud. Two people have access to databases. The infrastructure is modest by hyperscaler standards: Roughly 10 VMs in this division, with over 150 VMs across the broader group. Three Azure subscriptions. MySQL as the workhorse, with PostgreSQL and MongoDB supporting newer workloads.

The challenge is not complexity of scale. It is complexity of transition. This is an organisation moving from on-premises-first to hybrid-cloud, from traditional IT operations to modern platform engineering, and from endpoint-centric security to cloud-native security governance. The tooling has not made that transition yet.

The Core Challenge

A hybrid Azure and on-premises environment with databases holding sensitive candidate and employee data, governed by an endpoint management tool that was never designed for cloud-native access control, database-level security, or compliance evidence generation; all while SOC 2 and GDPR audits demand identity-stamped proof of who accessed what, when, and why.

Where the Gaps Were

Microsoft Intune: The Right Tool for Endpoints, the Wrong Tool for Cloud Access Governance

The team was using Microsoft Intune as their access governance mechanism. Intune is a capable endpoint management and device compliance platform that helps ensure devices are encrypted, policies are enforced, and corporate devices are properly enrolled. For a manufacturing conglomerate with thousands of employee devices across plants and offices, that is genuinely valuable.

But Intune was never designed to solve the problems this team actually faces in cloud security:

• No time-bound cloud access. Intune manages device compliance, not cloud-role elevation. It cannot grant a developer 2-hour access to an Azure subscription and auto-revoke it. Once a user has an Azure role, that role persists until someone manually removes it.
• No database-level access control. Intune has no concept of database sessions, query-level auditing, or dynamic PII masking. The two people with database access have standing credentials that never expire and are never scoped to specific tables or operations.
• No identity-stamped audit trail for cloud actions. Intune can tell you which devices are compliant. It cannot tell you which user ran which SQL query on which database at which time. These are the exact evidences SOC 2 and GDPR auditors require.
• No approval workflows for privileged access. There is no mechanism to request, approve, and time-box elevated access through Microsoft Teams (their collaboration tool) with a full audit trail of the decision chain.
• No coverage for non-human identities. Jenkins pipelines, service accounts, and API keys used by the AI platform are completely outside Intune’s governance model.

The gap is not a failure of Intune. It is a mismatch between what endpoint management solves and what cloud-native access governance requires. The team recognised this and explicitly stated their requirement: JIT and DAM.

Standing Database Access with No Visibility

Two people have permanent, unrestricted access to MySQL, PostgreSQL, and MongoDB databases that support the AI interview platform. These databases contain candidate personal data (names, interview recordings metadata, assessment results, employment history) all of which falls squarely under GDPR’s definition of personal data.

The current state:

• Permanent credentials. Database passwords that never rotate, never expire, and grant full access to all tables and all operations.
• No query-level audit. There is no record of what queries are executed, what data is read, or whether destructive operations (DROP, DELETE, TRUNCATE) have been run.
• No dynamic masking. When either user connects, they see all data in plaintext — including PII fields that they may not need for their specific task.
• No separation of duty. Both users have identical, full-privilege access regardless of whether they need to run a schema migration, debug a query, or generate a report.
• Shared credentials likely. With only two people and no JIT mechanism, the likelihood of shared database passwords (or passwords stored in plaintext configuration files) is high.

For a database holding personal data under GDPR, this is not just a security risk. It is an auditable compliance gap. Article 32 of GDPR requires “appropriate technical and organisational measures” to ensure security of processing. Standing, unaudited, full-privilege access to personal data does not meet that bar.

SOC 2 and GDPR Without the Evidence to Prove Compliance

The team requires both SOC 2 and GDPR compliance. Both frameworks demand specific evidence that the current tooling cannot generate:

SOC 2 (Trust Service Criteria; specifically CC6.1, CC6.2, CC6.3):

• Evidence that access to systems is restricted to authorised users only.
• Evidence that access is reviewed and modified based on changes in job responsibilities.
• Evidence that logical access to systems is removed when no longer needed.

With standing Azure roles that accumulate over time and no automated access review, the team cannot produce this evidence without weeks of manual log compilation.

GDPR (Articles 5, 25, 30, 32, 35):

• Article 5(1)(f): Personal data must be processed with “appropriate security.”
• Article 25: Data protection by design and by default; access to personal data should be limited to what is necessary.
• Article 30: Records of processing activities; who accessed what data, when.
• Article 32: Appropriate technical measures; including access control, encryption, and the ability to restore availability.

With no database-level audit trail, no dynamic masking, and permanent full-privilege access to databases containing personal data, the team has significant gaps against these articles.

The compliance requirement is not theoretical. SOC 2 auditors will ask: “Show me your access reviews for the last quarter.” GDPR Data Protection Officers will ask: “Who accessed personal data in this database, and was that access necessary for their role?” Today, the honest answer to both questions is: “We cannot produce that evidence systematically.”

Azure Security Posture Without Cross-Service Correlation

The team uses EntraID for Azure identity management. But, by their own description, “no tool” for security posture monitoring. Three Azure subscriptions, 10 VMs (150+ across the group), and a growing cloud footprint, with no automated mechanism to:

• Detect misconfigured network security groups exposing VMs to the internet.
• Identify over-permissioned Azure RBAC roles that grant access far beyond what is used.
• Surface unencrypted storage accounts or databases accepting connections without TLS.
• Monitor for anomalous behaviour, such as a user accessing resources at unusual times, from unusual locations, or performing unusual operations.
• Track configuration drift as the AI platform grows and new resources are deployed.

Azure-native tools (Microsoft Defender for Cloud, Azure Security Center) provide some of this signal, but they operate in isolation from the identity, access, and database layers. A misconfigured VM, the identity that can reach it, and the database behind it are three separate findings in three separate dashboards and not one correlated attack path.

Jenkins CI/CD Without Security Gates

The team uses Jenkins for CI/CD and GitHub for source code management. In most environments at this maturity stage, the CI/CD pipeline deploys without security quality gates; no SAST scanning in the pipeline, no secrets detection before code reaches production, no container image scanning before deployment. Jenkins plugins exist for these capabilities, but without a platform that correlates code-level findings with cloud-level posture, shift-left security remains a checkbox rather than a genuine risk-reduction mechanism.

The Cloudanix Solution: Cloud-Native Security for a Hybrid Manufacturing Enterprise

Cloudanix addresses this team’s requirements as a CNAPP+ platform covering the JIT access, Database Activity Monitoring, compliance evidence generation, and Azure security posture that their current tooling cannot provide.

Just-In-Time Access: Replacing Standing Privilege with Time-Bound, Audited Elevation

Cloudanix JIT Access directly replaces the standing privilege model that Intune cannot govern. The transition is from “5–7 people have permanent Azure access” to “5–7 people request scoped access when they need it, for the duration they need it, with full audit.”

How It Works for This Team

1. User requests access via Microsoft Teams (their existing collaboration tool). The request specifies: which Azure subscription, which resource group or VM, what role level, and for how long.
2. Approval routes to the designated approver, likely the IT Ops lead or Assistant Manager identified in the team structure. Approval workflows are configurable per resource sensitivity.
3. Access is granted for the approved duration only. The user receives a scoped Azure role assignment that automatically expires. No manual cleanup required.
4. Every action during the session is logged with identity attribution “what the user did, which resources they touched, what changes they made”.
5. Access auto-revokes. When the time window closes, the Azure role assignment is removed. The user returns to zero standing privilege.

Coverage Across Their Stack

• Cloud JIT: Time-bound elevation into Azure subscriptions and resource groups. A user needing to restart a VM gets 30-minute Contributor access to that specific resource group, and not permanent Contributor across all three subscriptions.
• VM JIT: Keyless SSH/RDP into Azure VMs without standing credentials. For the 9 servers running the AI platform, engineers get time-bound access that is recorded and auto-revoked. No more shared SSH keys or permanent RDP passwords.
• Database JIT: Time-bound, scoped database access replacing permanent credentials. The two people with database access request elevation when needed, receive credentials that expire automatically, and every query they run during the session is identity-stamped.
• Non-Human Identity Governance: Jenkins service accounts, API keys used by the AI platform, and any automated processes receive short-lived credentials rather than permanent secrets. This is particularly critical for a platform running on 9 servers with 4 databases — each connection is a credential that can be compromised.

Integration with Microsoft Teams

The team uses Microsoft Teams as their collaboration platform. Cloudanix integrates natively with Teams for access request and approval workflows:

• Users request access from within Teams.
• Approvers receive notifications and approve/deny directly in Teams.
• The full request → approval → grant → usage → revoke lifecycle is visible in a Teams channel, creating an organic audit trail that the team can review without logging into a separate console.

This means the access governance workflow lives where the team already works — not in a separate tool that requires context-switching.

What Changes for the 5–7 Cloud Users

Before (Intune + standing roles)	After (Cloudanix JIT)
Permanent Azure RBAC assignments	Zero standing privilege; access requested per task
No time limit on elevated access	Access auto-revokes after approved duration
No audit trail of access decisions	Full audit: who requested, who approved, what was done
Manual offboarding when roles change	Automatic — no access to revoke because none persists
No approval workflow	Teams-native request → approve → grant → revoke
Intune manages device compliance only	Cloudanix governs cloud identity and access

Database Activity Monitoring: Seeing Every Query, Masking Every PII Field

Cloudanix Database Activity Monitoring addresses the most urgent compliance gap: databases holding personal data with no visibility into who accesses what.

Coverage Across Their Database Stack

The team runs MySQL (primary), PostgreSQL, and MongoDB. Cloudanix DAM provides unified monitoring across all three:

• MySQL: Query-level monitoring for the primary database engine. Every SELECT, INSERT, UPDATE, DELETE is logged with identity attribution.
• PostgreSQL: Same depth for the databases supporting newer workloads.
• MongoDB: Document-level operation monitoring for the NoSQL tier.

All three database types (relational and document) under one monitoring layer. No separate tools per database engine.

Dynamic PII Masking

The AI interview platform stores candidate personal data. Under GDPR Article 25 (data protection by default), access to that data should be limited to what is necessary for the specific processing purpose.

Cloudanix dynamic masking enforces this at query time:

• A user querying candidate records for debugging sees masked PII fields (name, email, phone) unless their role explicitly requires plaintext access.
• Masking is role-based and applied in real-time with no separate masked database copies, no ETL pipelines to maintain.
• The same user can see full data for tables where they have legitimate need, and masked data for tables where they do not.

For two people with database access, this means the developer debugging a query performance issue does not automatically see candidate phone numbers and email addresses in the result set. That is data minimisation enforced at the platform level, not by policy alone.

Destructive Query Prevention

Databases holding business-critical data (interview records, assessment results, candidate profiles) need protection against accidental or malicious destruction:

• DROP and TRUNCATE operations can be blocked entirely or require explicit secondary approval before execution.
• Bulk DELETE operations beyond a configurable threshold trigger an alert or block.
• Schema changes (ALTER TABLE, DROP INDEX) can require approval workflows.

For a team of two database users, this is insurance against the fat-finger scenario. A mistyped DELETE FROM candidates without a WHERE clause is caught and blocked before data is destroyed.

Keyless Database Access via IDE

Engineers connect to MySQL, PostgreSQL, and MongoDB through their existing tools (DBeaver, DataGrip, TablePlus, pgAdmin, mongosh) without ever seeing or storing database credentials:

• Authentication is handled through their identity (EntraID) with no shared passwords, no credentials in .env files, no secrets in Jenkins configurations.
• Access is time-bound and scoped to the specific database and operations approved in the JIT request.
• Every session is identity-stamped: Audit trail shows exactly which person ran which query, not which shared credential was used.

Audit Trail in Customer-Owned Storage

All database activity logs land in the customer’s own Azure Blob Storage:

• Complete data sovereignty over the audit trail.
• No database activity data leaves the customer’s Azure environment.
• Audit evidence is available for SOC 2 and GDPR compliance reviews without requesting exports from a third-party vendor.

Compliance Evidence Generation: SOC 2 and GDPR on Autopilot

Cloudanix maps security findings and access activity directly to compliance frameworks, generating audit-ready evidence without weeks of manual preparation.

SOC 2 Evidence (Trust Service Criteria)

SOC 2 Control	Cloudanix Evidence
CC6.1 Logical access restricted to authorised users	JIT access logs showing every elevation was requested, approved, time-bound, and auto-revoked
CC6.2 Access reviewed and modified based on role changes	Continuous access reviews showing no standing privilege; access only exists during active JIT sessions
CC6.3 Access removed when no longer needed	Automatic revocation logs showing access expiry for every JIT session
CC6.6 Security events monitored and responded to	Azure activity monitoring + anomaly detection across all three subscriptions
CC7.2 Anomalous behaviour detected	UEBA baseline for the 5–7 cloud users; deviations flagged in real-time

For a SOC 2 audit, the team produces this evidence with a single export — not weeks of manual log collection across Azure Activity Logs, EntraID, and database server logs.

GDPR Evidence (Key Articles)

GDPR Article	Cloudanix Evidence
Art. 5(1)(f) Integrity and confidentiality	Database access is time-bound, identity-stamped, and all queries are logged
Art. 25 Data protection by design/default	Dynamic PII masking enforced at query time; access scoped to minimum necessary
Art. 30 Records of processing	Complete query-level audit trail: who accessed which personal data, when, for what purpose
Art. 32 Appropriate technical measures	JIT access (no standing privilege), destructive query prevention, automated access revocation
Art. 33/34 Breach notification	Real-time monitoring of database activity enables rapid detection of unauthorised access to personal data

The GDPR evidence gap “we cannot prove who accessed personal data and whether that access was necessary” is closed entirely by the combination of JIT + DAM + query-level auditing.

15+ Framework Coverage

Beyond SOC 2 and GDPR, the team’s growing compliance surface is covered:

• ISO 27001 information security management (relevant as the conglomerate expands digital operations).
• CIS Benchmarks Azure-specific hardening validation.
• NIST Cybersecurity Framework if US operations or customers require it.

All frameworks are mapped to the same underlying findings and access activity; one data set, multiple compliance views. As the organisation’s compliance requirements grow with digital expansion, new frameworks are a configuration change, not a new tool.

Azure CSPM: Posture Visibility Across Three Subscriptions

Cloudanix connects to all three Azure subscriptions via read-only roles. Agentless. No infrastructure changes. The 30-minute onboarding provides immediate posture visibility:

What the Team Gains

• Unified dashboard across all three Azure subscriptions. Findings are not siloed by subscription; they are correlated across the environment.
• 1,000+ security checks covering Azure VMs, storage accounts, network security groups, EntraID configuration, Key Vault settings, and Azure-specific services.
• Misconfiguration detection for the 10 VMs and associated resources: public IP exposure, unencrypted disks, overly permissive NSG rules, missing diagnostic logging.
• Identity risk assessment for EntraID: over-permissioned roles, unused role assignments, service principals with excessive access, MFA gaps.
• GenAI-powered remediation for every finding: step-by-step fix instructions with copy-paste-ready Azure CLI commands and ARM/Bicep templates.

Attack Path Visibility

A misconfigured NSG on a VM is a finding. That VM being accessible from the internet, running the AI interview platform, connected to a database holding candidate PII, accessible by a user with standing admin credentials — that is an attack path. Cloudanix surfaces the path, not just the individual findings, enabling the team to prioritise based on actual exploitability rather than CVSS scores alone.

Hybrid Visibility

The team operates both on-premises and Azure. While Cloudanix’s CSPM focuses on the cloud tier, the JIT and DAM capabilities extend to databases and VMs regardless of where they are hosted. A MySQL instance running on-premises receives the same JIT access control and query-level monitoring as an Azure Database for MySQL. This is critical for a manufacturing conglomerate where the on-premises footprint will not disappear overnight.

Code Security: Catching Issues Before They Reach Production

The team uses GitHub for source code and Jenkins for CI/CD. Cloudanix Code Security provides:

• Secrets detection: Scanning for hardcoded database credentials, API keys, and Azure service principal secrets in code. For a team running Jenkins with database connections, this catches the credentials that inevitably end up in configuration files.
• SAST (Static Application Security Analysis): Identifying vulnerabilities in the AI platform’s codebase before deployment.
• SCA (Software Composition Analysis): Detecting vulnerable dependencies in the application stack.
• PR-level annotations: Security findings surfaced as comments on pull requests in GitHub, so developers see issues before code merges, and not after it reaches production.

For a new AI platform in active development, catching security issues at the code level prevents them from becoming cloud-level incidents.

Platform Impact

30 min Agentless onboarding per Azure subscription | 3 subscriptions Unified in a single dashboard | 5–7 cloud users Under JIT governance | 2 database users With query-level audit | 4 databases (MySQL, Postgres, MongoDB) under DAM | SOC 2 + GDPR Evidence on single-click export | Zero standing privilege Via time-bound JIT access

Why Endpoint Management Tools Cannot Solve Cloud Access Problems

The team’s use of Microsoft Intune for access governance is a pattern common in manufacturing and industrial conglomerates making the cloud transition. The logic is intuitive: “We already have Intune for device management; can it also handle cloud access?” The answer is: partially, but with fundamental gaps.

Endpoint management platforms were designed to answer: “Is this device compliant? Is it encrypted? Is it enrolled in our MDM?” They were not designed to answer: “Should this person have access to this Azure subscription right now? What did they do with that access? When should it be revoked?”

The distinction matters for three reasons:

1. Granularity. Endpoint compliance is binary (compliant or not). Cloud access governance requires continuous gradation: which subscription, which resource group, which role, for how long, approved by whom.
2. Temporality. Device compliance is persistent (the device is either enrolled or it is not). Cloud access should be ephemeral: granted for a task, revoked when the task is complete.
3. Audit depth. Endpoint management logs device state. Cloud access governance must log user actions at the API call and database query level — the evidence that SOC 2 and GDPR require.

Organisations making the transition from on-premises-first to hybrid-cloud consistently hit this gap. The tools that served them well for device and endpoint security do not extend into cloud identity, access, and data governance. That is not a criticism of those tools. It is a recognition that cloud-native security is a different problem requiring a different architecture.

The Outcome

The organisation gains a unified platform that replaces the patchwork of endpoint management, manual access governance, and missing database visibility with purpose-built cloud-native security:

Key Results

✅ Zero Standing Privilege: JIT replaces permanent Azure roles and database credentials for all cloud and database users. ✅ Complete Database Audit Trail: Every query across MySQL, PostgreSQL, and MongoDB is identity-stamped and logged to customer-owned storage. ✅ Dynamic PII Masking: Candidate personal data in the AI platform’s databases is masked by default; plaintext access only when role-justified. ✅ SOC 2 + GDPR Evidence on Demand: Compliance evidence generated from the same JIT and DAM activity data; single-click audit export replacing weeks of manual preparation. ✅ Destructive Query Prevention: DROP, TRUNCATE, and bulk DELETE operations blocked or require approval before execution. ✅ Microsoft Teams Integration: Access request and approval workflows live in the collaboration tool the team already uses. ✅ Unified Azure Posture: Three subscriptions, 10 VMs, and associated resources monitored under one dashboard with 1,000+ security checks. ✅ Code Security Gates: Secrets, vulnerabilities, and dependency risks caught in GitHub PRs before reaching production. ✅ 30-Minute Onboarding: Agentless, read-only connection to Azure. Findings the same day.

Running Hybrid Azure Infrastructure with Standing Privileges and Compliance Requirements?

If your organisation is transitioning from on-premises to Azure, managing database access with permanent credentials, facing SOC 2 or GDPR audits without systematic evidence, or relying on endpoint management tools for cloud access governance — Cloudanix was built for exactly this inflection point. JIT access, Database Activity Monitoring, compliance automation, and Azure CSPM without adding five more tools to your stack.

Book a Free Assessment to see your Azure environment through Cloudanix unified findings, access governance, database monitoring, and compliance evidence in under 30 minutes.

Related Resources

• The End of Permanent Access: Next-Generation JIT for Granular Database Security
• PAM for Credential Management, Password Rotation, and More in the Cloud
• Mastering Third-Party Access with a Just-in-Time Approach
• How to Implement JIT Access in AWS, Azure & GCP
• What is CNAPP (Cloud Native Application Protection Platform)?
• Database Activity Monitoring: Real-Time Data Security
• Understanding Privileged Access Management