Most organizations still think of their security perimeter as a network boundary. Attackers stopped thinking that way years ago. 

Today, the perimeter is identity, and the most exploited gap inside it is the standing admin account that nobody has reviewed in eighteen months.

After a series of high-profile cyber attacks targeting U.S. companies, the Cybersecurity and Infrastructure Security Agency (CISA) is urging organizations to harden their endpoint security by using least privilege when designing admin roles, enforcing multi-factor authentication (MFA) and deploying Privileged Identity Management (PIM) across Microsoft Intune, Entra ID, and other Microsoft software.

The problem is that too many people are ignoring this guidance.

If your administrators sign in every morning with permanent privileged access, you have a perimeter problem. This is the same perimeter problem that cyber insurers, regulators, and auditors are now asking about by name.
 

Why Identity Became the Front Line for Cyber Attacks
 

The shift is straightforward. Workloads moved to cloud platforms, users moved to anywhere they could use a browser, and the firewall stopped being the thing standing between an attacker and your data. 

Now, credentials are the thing standing between an attacker and your data. Credentials are far easier to phish than firewalls are to breach.

Microsoft’s own incident telemetry consistently shows identity compromise as the dominant initial access vector for ransomware, business email compromise, and lateral movement. Once an attacker has a valid session, traditional endpoint defenses do not see a problem: the user signed in correctly, the device is enrolled, the access token is legitimate. 

The attacker is now operating as your finance director, your IT admin, or your service account, and the security tools that are supposed to flag intrusions see only normal behavior.

This is why identity is now treated as a primary control surface, not a side concern owned by the helpdesk.

 

The Standing Privilege Problem

Privileged access is the highest-value target in any environment. A compromised user account is a problem. A compromised global admin, domain admin, or service account with broad permissions is a crisis.

The legacy model granted privileged rights permanently. Engineers and administrators logged in with elevated access by default, used it for routine work, and rarely had it revoked. 

The attack surface this creates is constant: every privileged account is a persistent target, every active session is a potential pivot point, and every long-lived credential is one phishing email away from full compromise.

The modern answer is just-in-time elevation. Privileged access is granted on request, for a specific task, for a defined window, and is automatically revoked when the window closes. 

Standing privilege drops to near zero. The attack surface shrinks to whatever short-lived elevations are active at any given moment, which is a far smaller target than a directory full of permanent admins.
 

What Underwriters and Auditors Now Expect
 

Cyber insurance underwriting changed materially in the past two years. Carriers that used to ask whether you had MFA now ask where you have MFA, where you do not, and what evidence you can produce that it stays enforced. 

They ask about privileged access management directly. They ask about audit trails for elevated sessions, about access reviews, about how you detect and respond to identity anomalies.

Compliance frameworks have moved in the same direction. PCI DSS 4.0, HIPAA, SOC 2, and ISO 27001 all reference privileged access governance, just-in-time access, and demonstrable identity controls. “We have admins, we trust them, here are the logs from our Security Information and Event Management (SIEM)” is not the answer that satisfies an auditor in 2026.

The control set that satisfies both audiences is consistent: enforced MFA on every access path, conditional access policies that evaluate device, location, and risk, just-in-time privileged elevation, and immutable audit evidence of who got what access, when, and why.
 

How CloudFirst Protects Identity in the Unified Defense Framework

CloudFirst’s Unified Defense Framework (UDF) treats identity as a Foundation-level control, not an optional add-on. Every UDF engagement starts with an identity baseline: Entra ID Conditional Access policies enforcing MFA, blocking legacy authentication, evaluating device compliance through Intune, and applying Zero Trust principles by default.

From there, the Assurance level layers on Microsoft Privileged Identity Management to eliminate standing privilege, and Microsoft Purview to produce the audit trail that proves the controls are working. Our 24x7 security operations center (SOC) continuously monitors identity telemetry, treating identity anomalies with the same urgency as endpoint detections. In most modern attacks identity is the first signal that anything is wrong.

This is not a license-and-leave engagement. We deploy, configure, monitor, and continuously manage the Microsoft identity stack as part of an integrated security operation. 

The output is a defensible identity posture, evidence ready for underwriters and auditors, and a meaningful reduction in the privileged attack surface that drives most successful breaches.

Extending Modern Identity Management to IBM i
 

Modern identity controls do not have to stop at the cloud edge. For organizations running IBM i workloads, the same Entra ID identity that signs in to Microsoft 365 can authenticate users into 5250 sessions, NetServer file shares, and IBM i applications, with no separate IBM i password to remember, rotate, or leak.

The bridge is hybrid identity. Entra Connect synchronizes Entra ID users with on-prem Active Directory, and IBM i participates in that AD domain through Network Authentication Service (NAS) and Enterprise Identity Mapping (EIM). 

When a user signs in to their workstation, Conditional Access and MFA enforce policy at the sign-in event, and the resulting Kerberos ticket grants access to IBM i without a second authentication. 

For Single Sign-On (SSO)-enabled accounts, the IBM i password can be set to *NONE, removing a credential surface that still exists in most IBM i environments today. As a side benefit, plain-text 5250 telnet credentials disappear, NetServer file share lockouts caused by mismatched stored credentials disappear, and IBM i password reset tickets stop arriving at the help desk.

CloudFirst Senior Systems Engineer Nathan Williams documented the IBM i side of this configuration in detail during his COMMON POWERUp 2026 session. The full step-by-step guide, including NAS configuration, EIM domain setup, identifier mapping, ACS client configuration, and the DNS and time-sync gotchas that derail most rollouts, is on the CloudFirst blog: How to Set Up Single Sign-On for IBM i.

The strategic point: the Conditional Access, PIM, and audit-evidence story that applies to your Microsoft estate extends to IBM i automatically once the hybrid identity bridge is in place, because the identity Entra is governing is the same identity IBM i is now trusting.

Hybrid is the most common path because most IBM i shops already run Active Directory (AD), but it is not the only one. 

For cloud-native organizations with no on-prem AD, Microsoft Entra Domain Services can present an AD-compatible Kerberos domain in Azure that IBM i NAS can join. 

For IBM i workloads that are primarily web-fronted, Entra ID can federate directly to those applications via SAML or OIDC, with EIM handling the mapping to IBM i profiles. 

And where AD is off the table and the protocol mix is awkward, third-party identity brokers can bridge Entra ID to IBM i through exit programs and sign-on servers. Each path has trade-offs worth scoping against your actual workload mix and roadmap, which is the conversation we have at the start of an identity assessment.
 

Where to Start with Identity and Access Management
 

If your environment still has permanent global admins, shared admin accounts, or service accounts with credentials that have not rotated in years, identity is the right first conversation. 

A Foundation-level assessment under UDF will surface the gaps, prioritize remediation, and establish the documented baseline that everything else depends on.

The perimeter has moved. The control set has moved with it. The organizations that recognize this early are the ones whose insurance renewals and audit findings get easier, not harder, every year.

Don’t wait until it’s too late to protect your data and IT infrastructure. 

Contact CloudFirst to schedule a free consultation

 

Frequently Asked Questions
 

What is privileged identity management?

Privileged Identity Management (PIM) is the practice of granting elevated access only when needed, for a defined time window, with approval and audit trails attached. Microsoft PIM is the implementation built into Entra ID. The goal is to eliminate standing privileged access, which is the persistent target attackers most want to compromise.

How does Conditional Access fit with PIM?

Conditional Access evaluates every sign-in against policy: who the user is, what device they are on, where they are signing in from, and what risk signals are present. PIM controls what privileges that user can elevate to once they are signed in. Together they enforce that the right person, on a trusted device, gets the right access, only when they need it.

Do we still need MFA if we have PIM?

Yes. MFA verifies the user at sign-in. PIM controls what they can do after sign-in. They solve different problems and both are required by every major compliance framework and most cyber insurance policies.

How does this affect IBM i environments?

IBM i has its own privileged access concerns, including QSECOFR and powerful user profiles. CloudFirst’s IBM i Managed Security Services include user profile swapping policies, exit point monitoring, and MFA for high-privilege users, mapping the same just-in-time principles to the IBM i platform. For SSO, IBM i can join the same identity bridge through Network Authentication Service and Enterprise Identity Mapping, allowing Entra ID identities (synchronized via Entra Connect to on-prem AD) to authenticate users into IBM i without a separate password. See our step-by-step guide How to Set Up Single Sign-On for IBM i, and our IBM i security tiers (SIP, RDAC, SMS) for how the broader posture is operationalized.

How long does an Entra plus PIM rollout take?

For a typical mid-market environment, the Foundation identity baseline is established in weeks, not months. PIM rollout depends on how many privileged roles exist and how access reviews are structured, but most organizations reach a defensible posture within a single quarter under UDF.

Contact CloudFirst