Identity Is the New Perimeter: Access, Authentication, and Control That Actually Hold Up

Part 3 of a series on creating information security policies.

Attackers don’t break in…they log in.

That’s a bit of a dramatic exaggeration, and it seems cliché, but it’s not really too far off.

Consider the 2022 Uber breach. The attacker didn’t exploit a sophisticated vulnerability; they obtained a contractor’s credentials and then bombarded the user with MFA push requests until one was approved. That single moment of fatigue opened the door to internal systems and broader access.

Or look at the 2021 Colonial Pipeline attack. The initial entry point was a compromised VPN account that did not have multi-factor authentication enabled. One valid login was enough to trigger widespread operational disruption across critical infrastructure.

These major incidents aren’t outliers, but are case studies in how identity failures cascade. Attackers are no longer forced to break through hardened perimeters. They rather take advantage of weak access governance and overprivileged accounts.

That’s why Identity, Authentication, and Access Control remain under intense scrutiny in frameworks like ISO 27001 and SOC 2. Auditors and attackers understand the same thing: if identity controls fail, everything else becomes secondary.

To build a defensible environment (and walk into an audit with confidence – auditors know when you’re not confident), organizations need three pillars working in concert: strong Access Control, disciplined Privileged Access Management, and clearly enforced Authentication Standards.

Access Control Policy: Structure Over Sprawl

An Access Control Policy is where security becomes operational. It defines how access is granted, how it evolves, how it is validated over time, and ultimately how it is removed.

In practice, this policy is less about documentation and more about discipline. Without structure, access tends to sprawl—users accumulate permissions over time, roles blur, and “temporary” access quietly becomes permanent.

A well-constructed policy anchors itself in two principles: least privilege and role-based access control. Least privilege ensures that users have only what they need to do their job, nothing more. Role-based access control builds on that by assigning permissions to roles rather than individuals, which reduces inconsistency and simplifies oversight.

From an audit perspective, the real focus is lifecycle management. Auditors are not just asking whether access is appropriate today; they are asking whether there is a repeatable, enforceable process behind it.

That lifecycle typically includes four stages:

Provisioning: Access is granted based on a documented request, approved by the appropriate system or data owner, and tied to a clear business need.
Modification: Changes in role or responsibility kick off corresponding updates to access, rather than simply layering new permissions on top of old ones.
Review: Access is periodically revalidated – at least twice a year is often good enough.
Revocation: Access is promptly removed when no longer needed, especially with employee terminations.

Identity Is the New Perimeter: Access, Authentication, and Control That Actually Hold Up

Where organizations struggle most is not in defining these stages, but in proving they happen consistently. Reviews are performed but not documented; approvals occur informally; deprovisioning is a manual process that can be (is often?) delayed or missed; security awareness is hit-and-miss.

From a GRC (governance, risk, compliance) standpoint, these gaps are exactly the conditions attackers look for: dormant accounts, excessive privileges, and unclear ownership.

If you’re preparing for an audit, one of the most effective exercises is also one of the simplest: export access lists from your critical systems and map users to roles. The discrepancies you find will often tell you more than any policy document.

Privileged Access Management: Controlling the Blast Radius

If Access Control defines the structure, Privileged Access Management (PAM) defines the stakes.

Privileged accounts operate with elevated authority. They change configurations, access sensitive data at scale, and bypass the very controls designed to protect the system. When compromised, they don’t just provide access – they provide control.

PAM is about containment, not convenience.

A mature approach to privileged access starts with separation (aka, segregation). Administrative access should be distinct from standard user access, ensuring that elevated privileges are used only when necessary. A common approach is to use something like “username” and “username-admin” to denote the different accounts. That keeps the name obvious, especially in logs for forensics and alerts. This separation reduces both accidental misuse and the impact of credential compromise.

From that point, organizations move toward time-bound access. Rather than assigning standing admin rights, privileged access is granted temporarily. often through a just-in-time model, and expiring automatically. This greatly reduces the window of opportunity for misuse.

Equally important is oversight (the governance type, not the “oops, I didn’t notice that!” type). Privileged actions shouldn’t happen in the dark. Logging, monitoring, and session recording provide visibility – the lighting, if you will – into what is being done and by whom. This visibility is decisive evidence during audits.

On the practical side, strong PAM programs share a few traits:

Privileged access requires explicit approval and is tied to a defined task or timeframe (make sure it’s documented)
Privileged activity is logged and regularly reviewed (don’t miss regular account reviews)
Administrative accounts are separate from day-to-day user accounts (“username” vs. “username-a”)

Auditors evaluating PAM controls are not necessarily expecting a fully mature, tool-driven implementation. What they are looking for is control and accountability: a clear inventory of privileged accounts, defined approval processes, and evidence that activity is monitored.

Without these controls, privilege escalation becomes the natural next step in an attack. A compromised user account is often just the beginning; the real damage occurs when that foothold turns into administrative control.

For organizations early in their quest (I like “quest” instead of something like “journey” because there’s more activity, introspection, and going down an unknown road in a quest) even a simplified “PAM-lite” approach can dramatically improve both security posture and audit readiness. This Lite approach involves eliminating shared admin accounts, enforcing MFA, and logging privileged actions.

Authentication Standards: Strengthening the Front Door

If access control governs who should have access, and PAM governs the most sensitive accounts, authentication determines how easily those controls can be bypassed.

Weak authentication undermines everything else.

An Authentication Standards policy (sample here: https://www.securitystudio.com/resources/identity-and-access-management-policy) defines the baseline expectations for verifying identity. This includes password practices, multi-factor authentication requirements, and the processes used to validate users during account recovery or support interactions.

Historically, password complexity rules dominated. Today, the emphasis is on length, uniqueness, and resistance to known breaches. Long passphrases are generally more effective and usable than short, complex strings, which make people more likely to reuse or write down.

Multi-factor authentication remains one of the most useful controls available. When implemented consistently, it significantly reduces the likelihood that a stolen password alone can lead to account compromise. MFA must be implemented thoughtfully. Push fatigue attacks (aka, MFA bombing)and phishing proxies have demonstrated that not all MFA methods offer equal protection.

Stronger approaches include authenticator apps with number matching, hardware security keys, and other phishing-resistant mechanisms. At minimum, MFA should be enforced for remote access, privileged accounts, and any system containing sensitive data.

Authentication standards also extend beyond login prompts. Account recovery processes, particularly help desk interactions, are a frequent target for social engineering. A well-defined policy ensures that identity is verified before credentials are reset or access is granted.

From an audit standpoint, the key aspect is consistent. It’s not enough to require MFA in policy; it has to be demonstrably enforced across systems (don’t forget – you have to LOVE screenshots to do an audit, so get used to taking them – I use Greenshot a lot!). Password standards must go beyond documentation to being applied in practice.

A quick internal assessment can reveal the gaps:

Where is MFA not enforced?
Are there justified exceptions?
How resistant is the password reset process to manipulation?

The answers to those questions align closely with real-world risk.

Why This Matters: Beyond Compliance

It’s tempting to view these controls as audit requirements, as boxes to check in preparation for ISO 27001 or SOC 2. But the reality is that these are controls that prevent breaches. They can be extremely annoying, but it’s very much a case where you don’t want to have to tell the company, “I told you so.”

When access is poorly governed, users gain unnecessary permissions.
When privileged accounts are loosely controlled, attackers escalate quickly.
When authentication is weak/inconsistent, credentials become the easiest way in.

These are compounding failures.

Identity has become a focal point of both security frameworks AND real-world attacks. Almost everything else in your environment is built on identity being trustworthy. When that ID foundation fails, defenses become reactive instead of preventive.

Final Thought: From Policy to Practice

There are 2 traps that orgs can fall into – lack of policies, and policies that don’t translate into consistent action: access reviews are scheduled but not completed, privileged activity is logged but not examined, MFA is required in theory/writing but bypassed in actual practice.

Audit readiness and real security come from closing that gap. (hint: do a gap analysis. Unsure what that is or means for your org? there’s lots out there; maybe I’ll write about it) Document your controls clearly, implement them consistently, and retain evidence that proves they’re working.

Attackers aren’t interested in your policies; they’re counting on the times when policies aren’t followed.

Stay vigilant!

Further Reading