Why Intune Is Not PAM for the Cloud: Transitioning to JIT Access and GDPR-Ready Database Security for Manufacturing

Manufacturing conglomerates are digitising faster than their security tooling can keep pace. New AI platforms, hybrid Azure infrastructure, and databases full of personal data, all governed by endpoint management tools that were never designed for cloud access control.

This article examines a pattern we see repeatedly: a global manufacturing enterprise relying on Microsoft Intune for privileged access management, while their actual security gaps (standing database credentials, no query-level auditing, and GDPR compliance without evidence) go unaddressed. We break down why endpoint tools cannot solve cloud access problems, what the transition to Just-In-Time access looks like in practice, and how manufacturing companies can achieve GDPR compliance for AI platforms running on Azure.

The Pattern: Manufacturing Digitisation Outpacing Security

Here is what this scenario typically looks like. A division within a global manufacturing conglomerate; one with operations spanning continents and over 150 VMs across the broader group launches a new AI-powered platform. The platform runs on 9 servers with 4 databases, handling sensitive personal data: candidate records, assessment results, interview metadata, employment history.

The infrastructure is hybrid. On-premises systems that have served the manufacturing core for decades sit alongside Azure cloud where new workloads land. Three Azure subscriptions. Five to seven people with cloud access. Two people with database access. MySQL as the primary database, with PostgreSQL and MongoDB supporting the newer workloads.

The compliance requirements are real: SOC 2 and GDPR. The auditors will come. The evidence must exist.

The security tooling? Microsoft Intune for “PAM.” Microsoft EntraID for Azure identity. No dedicated tool for cloud security posture, database access monitoring, or compliance evidence generation.

This is not a failure of the security team. This is an organisation in transition from on-premises-first to hybrid-cloud, from traditional IT operations to platform engineering, from device-centric security to identity-centric security. The gap is the tooling, not the intent.

Why Intune Is Not PAM for the Cloud

Microsoft Intune is a capable platform. It manages device compliance, enforces encryption policies, ensures corporate devices are properly enrolled, and handles application protection. For a manufacturing conglomerate with thousands of employee devices across plants, offices, and field operations, Intune solves a genuine problem.

But when teams describe Intune as their “PAM solution,” they are conflating endpoint privilege management with cloud access governance. These are fundamentally different problems.

What Intune Does Well

• Device compliance: Is this laptop encrypted? Is it enrolled in the MDM?
• Endpoint privilege management: Can this user run elevated applications on their Windows device?
• Application protection: Are corporate apps sandboxed on personal devices?
• Conditional access integration: Is this device compliant before it accesses corporate resources?

What Intune Cannot Do (and Was Never Designed to Do)

• It cannot grant time-bound cloud access. Intune manages whether a device is compliant. It does not manage whether a user should have Contributor access to an Azure subscription right now, for the next two hours, to complete a specific task. Once an Azure RBAC role is assigned, it persists indefinitely until someone manually removes it.

• It cannot govern database access. Intune has zero concept of database sessions, SQL queries, or data-level permissions. The two people with database access in our scenario have standing credentials e.g. passwords that never expire, never rotate, and grant full access to every table and every operation. Intune cannot see this, let alone control it.

• It cannot produce identity-stamped audit trails for cloud actions. Intune tells you which devices are compliant. It cannot tell you which user ran which SQL query against which database at which timestamp. These are precisely the evidences that SOC 2 and GDPR auditors demand.

• It cannot provide approval workflows for privileged elevation. There is no mechanism to request, approve, and time-box elevated Azure access through Microsoft Teams (or any channel), with a full audit trail of the decision chain.

• It cannot govern non-human identities. Jenkins pipelines, service accounts, API keys used by AI platforms are completely outside Intune’s governance model. And in a 9-server, 4-database deployment, every connection is a credential that can be compromised.

The Real Problem: Architecture Mismatch

The gap is not a criticism of Intune. It is a category mismatch. Endpoint management and cloud access governance solve different problems at different layers of the stack:

	Endpoint Management (Intune)	Cloud Access Governance (JIT)
What it governs	Devices	Identities and resources
Granularity	Binary (compliant/not)	Continuous (which resource, which role, how long)
Temporality	Persistent (device is enrolled or not)	Ephemeral (access granted per task, auto-revoked)
Audit depth	Device state	API calls, SQL queries, identity actions
Scope	Endpoints	Cloud, databases, VMs, Kubernetes, SaaS

Organisations making the cloud transition consistently hit this gap. The tools that served them well for device security do not extend into cloud identity, database access, and data governance. Recognising this mismatch is the first step toward closing it.

The Transition: From Standing Privilege to Just-In-Time Access

The transition from endpoint-focused PAM to cloud-native JIT access is not a rip-and-replace. Intune continues to serve its purpose (device compliance, endpoint management). What changes is that cloud access governance gets a purpose-built solution.

Before: The Standing Privilege Model

In a typical manufacturing environment relying on Intune:

• 5–7 cloud users have permanent Azure RBAC roles. No expiry. No time-boxing. No automatic revocation when tasks complete.
• 2 database users have permanent credentials. Full access to MySQL, PostgreSQL, and MongoDB. Every table, every operation, indefinitely.
• Service accounts (Jenkins, APIs) use long-lived secrets stored in configuration files or environment variables.
• No access decisions are recorded. Who approved this access? When? For what purpose? There is no answer.
• Offboarding is manual. When someone changes roles, their accumulated access persists until someone remembers to remove it.

After: Zero Standing Privilege with JIT

With Cloud JIT, the model inverts:

1. A user needs access to an Azure subscription to troubleshoot a production issue on the AI platform.
2. They request it via Microsoft Teams specifying which subscription, which resource group, which role level, and for how long.
3. The designated approver (IT Ops lead, engineering manager) approves or denies directly in Teams. The approval is logged.
4. Access is granted for the approved duration only. A scoped Azure role assignment is created with an automatic expiry.
5. The user completes their task. Every action they take during the session, every resource they touch, every change they make is identity-stamped and logged.
6. Access auto-revokes. When the time window closes, the role assignment is removed. The user returns to zero standing privilege. No manual cleanup required.

Coverage Across the Full Stack

For a manufacturing organisation running hybrid Azure + on-premises with multiple database technologies, JIT needs to cover more than just cloud console access:

• Cloud JIT: Time-bound elevation into Azure subscriptions and resource groups. A developer needing to restart a VM gets 30-minute Contributor access to that specific resource group; and not a 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 recorded, time-bound access that auto-revokes. No shared SSH keys.
• Database JIT: Time-bound, scoped database access replacing permanent credentials. Database users request elevation when needed, receive credentials that expire automatically, and every query during the session is identity-stamped.
• Non-Human Identity governance: Jenkins service accounts, API keys, and automated processes receive short-lived credentials. Each connection is scoped and time-bound.

What Changes for the Team

Before (Intune + standing roles)	After (JIT)
Permanent Azure RBAC assignments	Zero standing privilege; access requested per task
No time limit on elevated access	Auto-revocation after approved duration
No audit trail of access decisions	Full audit: who requested, who approved, what was done
Manual offboarding	Automatic: no access to revoke because none persists
No approval workflow for cloud access	Teams-native request → approve → grant → revoke
Device compliance only	Cloud, database, and VM identity governance

GDPR Compliance for Manufacturing: The Database Evidence Gap

For manufacturing companies operating AI platforms that process personal data (candidate records, employee information, assessment results) GDPR compliance is not optional. And it is precisely where the gap between endpoint management and cloud access governance becomes a legal liability.

What GDPR Requires for Database Access

GDPR does not merely require that personal data is “protected.” It requires specific, demonstrable controls:

• Article 5(1)(f) Integrity and Confidentiality: Personal data must be processed with “appropriate security,” including protection against unauthorised access.
• Article 25 Data Protection by Design and Default: Access to personal data should be limited to what is necessary for the specific processing purpose. This is the principle of data minimisation applied to access control.
• Article 30 Records of Processing Activities: Organisations must maintain records of who accessed personal data, when, and for what purpose.
• Article 32 Appropriate Technical Measures: This includes access control mechanisms, encryption, and the ability to detect and respond to breaches.
• Articles 33/34 Breach Notification: If personal data is compromised, organisations must notify the supervisory authority within 72 hours and affected individuals without undue delay.

The Evidence Manufacturing Teams Cannot Produce Today

With standing database credentials, no query-level audit trail, and Intune governing only device compliance, the manufacturing team in our scenario cannot answer the questions GDPR auditors will ask:

• “Who accessed candidate personal data in the last quarter?” → We don’t have query-level logging.
• “Was that access necessary for their specific role?” → Both users have identical full-privilege access.
• “How do you enforce data minimisation at the database level?” → We don’t. Both users see all data in plaintext.
• “Can you demonstrate that access was time-bound and purpose-limited?” → No. Access is permanent.
• “How quickly can you detect unauthorised access to personal data?” → We have no real-time database monitoring.

This is not a theoretical compliance risk. When a Data Protection Officer or auditor asks these questions (and they will) the honest answer with current tooling is: “We cannot produce that evidence systematically.”

Closing the Gap: Database Activity Monitoring

Database Activity Monitoring (DAM) addresses the GDPR evidence gap directly by providing visibility into what happens inside the database. Not just who connects, but what they do after connecting.

Query-Level Auditing Across Multiple Database Technologies

Manufacturing environments rarely run a single database technology. Our scenario includes MySQL (primary), PostgreSQL, and MongoDB. DAM provides unified monitoring across all three:

• Every SELECT, INSERT, UPDATE, DELETE on relational databases is logged with identity attribution.
• Document-level operations on MongoDB are monitored.
• The audit trail answers: who ran which query, against which table, at which timestamp, returning how many rows.

Dynamic PII Masking

An AI interview platform storing candidate personal data (names, phone numbers, email addresses, assessment scores, employment history) needs access control that goes beyond “can connect” vs. “cannot connect.”

Dynamic masking enforces GDPR’s data minimisation principle at query time:

• A developer debugging a performance issue sees masked PII fields unless their role explicitly requires plaintext access.
• Masking is applied in real-time — no separate masked database copies, no ETL pipelines.
• The same user can see structural data they need for debugging without seeing the personal data they do not need.

For two people with full database access, this is the difference between GDPR compliance by policy (a document that says “don’t look at PII”) and GDPR compliance by design (a technical control that enforces it).

Destructive Query Prevention

Databases holding irreplaceable personal data (interview recordings metadata, candidate profiles, assessment histories) need protection against both accidental and malicious destruction:

• DROP and TRUNCATE operations are blocked entirely or require secondary approval.
• Bulk DELETE operations beyond a configurable threshold trigger alerts or blocks.
• Schema changes (ALTER TABLE, DROP INDEX) can require approval workflows.

For a small team with direct database access, this is insurance against the DELETE FROM candidates without a WHERE clause scenario. The data loss is prevented before it happens.

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. The evidence never leaves the customer’s environment.
• GDPR Article 30 compliance records of processing activities are maintained systematically.
• Audit evidence is available for compliance reviews without requesting exports from a third-party vendor.

GDPR Evidence Mapping

GDPR Article	How It Is Satisfied
Art. 5(1)(f) Integrity and confidentiality	Database access is time-bound, identity-stamped, and every query is 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 (zero standing privilege), destructive query prevention, automated revocation
Art. 33/34 Breach notification	Real-time monitoring enables rapid detection of unauthorised access to personal data

Securing AI Platforms on Azure: The New Manufacturing Workload

The emergence of AI-powered platforms within manufacturing organisations introduces a workload category that traditional security tooling was not designed to protect. An AI interview platform running on 9 servers with 4 databases is not a conventional enterprise application. It has distinct security requirements.

What Makes AI Platforms Different

Sensitive data concentration. An AI interview platform aggregates candidate personal data at scale: biometric markers from video interviews, psychometric assessment results, employment histories, contact information. This is GDPR personal data and potentially special category data depending on what the assessments evaluate.

Rapid iteration. AI platforms are under active development. New models are trained, new features are shipped, infrastructure changes frequently. The attack surface moves fast.

Multiple database technologies. AI workloads often require different database engines for different purposes. For e.g. MySQL for application state, PostgreSQL for structured analytics, MongoDB for unstructured data and embeddings. Each is an access surface.

Service-to-service communication. The 9 servers communicate with each other and with the 4 databases through API keys, service accounts, and connection strings. Each connection is a credential that can be compromised.

CI/CD as an access vector. Jenkins deploying to these servers needs credentials. Those credentials, if long-lived and over-scoped, represent a lateral movement path from CI/CD compromise to production data.

The Security Architecture for AI Platforms on Azure

Layer 1: Azure CSPM: Posture Visibility

Connect all three Azure subscriptions via read-only roles. Agentless. No infrastructure changes. In 30 minutes, gain visibility into:

• Misconfigured network security groups exposing VMs to the internet.
• Over-permissioned Azure RBAC roles that grant access beyond what is used.
• Unencrypted storage accounts or databases accepting connections without TLS.
• Attack paths — not just individual misconfigurations, but the chain: public IP → misconfigured NSG → VM running the AI platform → database with candidate PII → user with standing admin credentials.

For the 9 servers hosting the AI platform, CSPM answers: “Are these servers configured securely?” Attack path analysis answers: “What happens if one of them is compromised?”

Layer 2: JIT Access: No Standing Credentials

Every human and non-human identity that touches the AI platform infrastructure operates under zero standing privilege:

• Developers request time-bound access to specific VMs or database instances when they need to debug, deploy, or investigate.
• Jenkins pipelines receive short-lived credentials scoped to the specific deployment task. When the pipeline completes, the credential expires.
• Database users connect through identity-based, time-bound sessions; not shared passwords in .env files.

Layer 3: Database Activity Monitoring: Visibility into Data Access

The 4 databases are the crown jewels. DAM provides:

• Real-time monitoring of every query across MySQL, PostgreSQL, and MongoDB.
• Dynamic PII masking for candidate personal data.
• Destructive query prevention for business-critical tables.
• Identity-stamped audit trail for every database session.
• Keyless database access through existing IDE tools (DBeaver, DataGrip, TablePlus, pgAdmin) — engineers never see or store database passwords.

Layer 4: Code Security: Catching Issues Before Production

With GitHub for code and Jenkins for CI/CD, code security provides:

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

Microsoft Teams Integration

The entire access governance workflow lives in Microsoft Teams, the collaboration tool the team already uses:

• Access requests submitted in Teams.
• Approvals handled in Teams.
• The full request → approval → grant → usage → revoke lifecycle visible in a Teams channel.
• An organic audit trail the team can review without logging into a separate console.

No context-switching. No new tools to learn. Security governance becomes part of the existing workflow.

The Compliance Payoff: SOC 2 + GDPR Evidence on Demand

The combination of JIT access (zero standing privilege), Database Activity Monitoring (query-level audit), and Azure CSPM (posture visibility) produces compliance evidence as a byproduct of daily operations — not as a quarterly fire drill.

SOC 2 Evidence

SOC 2 Control	Evidence Produced
CC6.1 Logical access restricted	JIT logs: every elevation requested, approved, time-bound, auto-revoked
CC6.2 Access reviewed based on role changes	Continuous: no standing privilege; access only exists during active sessions
CC6.3 Access removed when no longer needed	Automatic revocation logs for every JIT session
CC6.6 Security events monitored	Azure activity monitoring + anomaly detection across all subscriptions

GDPR Evidence

GDPR Article	Evidence Produced
Art. 5(1)(f) Integrity and confidentiality	Time-bound, identity-stamped database access with full query logging
Art. 25 Data protection by design/default	Dynamic masking enforced at query time; access scoped to minimum necessary
Art. 30 Records of processing	Query-level audit trail: who, what, when, why is systematically maintained
Art. 32 Appropriate technical measures	JIT + destructive query prevention + automated revocation

One export. Not weeks of manual log collection across Azure Activity Logs, EntraID, and database server logs.

Key Takeaways for Manufacturing Security Teams

1. Intune is not cloud PAM. It is endpoint management. Continue using it for device compliance. Add purpose-built cloud access governance for identities, resources, and databases.

2. Standing database credentials are a GDPR liability. Two people with permanent, full-privilege access to databases containing personal data cannot satisfy Articles 25, 30, or 32. The fix is time-bound, scoped, audited access.

3. AI platforms need layered security. Azure posture + JIT access + database monitoring + code security — not as separate tools, but as one platform with one audit trail and one compliance export.

4. The transition does not require rip-and-replace. Intune stays. EntraID stays. What changes is that a security layer purpose-built for cloud, database, and identity governance sits alongside them — covering the surfaces they were never designed to reach.

5. Compliance evidence should be a byproduct, not a project. When access is JIT-governed and databases are monitored at query level, SOC 2 and GDPR evidence generates itself. The quarterly fire drill becomes a single-click export.

Running Azure Infrastructure with Intune as Your Only Access Governance?

If your manufacturing organisation is digitising rapidly, launching AI platforms, managing database access with permanent credentials, and facing SOC 2 or GDPR audits without systematic evidence — this is the inflection point where endpoint management stops being enough.

Book a Free Assessment to see your Azure environment through unified posture, access governance, database monitoring, and compliance evidence. Agentless. 30 minutes. Findings the same day.

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
• 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
• Mastering Third-Party Access with a Just-in-Time Approach