Privilege, Not Passwords: Where the Real Risk Lives

I wrote this for a class post and thought it was worth capturing here as well, both to share and for my own future documentation of where I landed on this.

I've been following a debate that keeps resurfacing — in our own classroom, in vendor briefings, and in boardrooms alike: which is the bigger security problem, weak passwords or weak privilege management? Most people settle firmly into one of two camps. Having spent more than one season of my career building and contributing to an identity management product, I'd like to try bridging the gap — though I'll confess up front that I've already picked a side. Privilege is the bigger governance and management problem, and it deserves the stronger focus. Let me explain.

Password vulnerability is a real problem, but the initial breach of an organization's systems through a login is, at this point, close to inevitable. Most large breaches begin with adversary-in-the-middle (AitM) phishing that bypasses MFA, or with infostealer malware quietly harvesting credentials by the thousands. And service accounts, by their nature, cannot use MFA at all. So under an assume-breach mindset, the decisive question is not whether an account will be compromised, but what that account can then access. A typical user account can be contained as an incident. An over-privileged identity is something else entirely: an attacker can escalate from it, disable security tooling, move laterally across the network, and establish the command-and-control foothold that turns a phishing click into a ransomware event. The privilege granted to the initially compromised identity determines the blast radius of the incident.

Meanwhile, the password problem is slowly solving itself, for the most part. NIST's recently finalized SP 800-63B-4 (National Institute of Standards and Technology [NIST], 2025) decisively shifts password guidance toward length, breached-credential screening, and phishing-resistant authentication. I've written before about my enthusiasm for moving toward passwordless login using passkeys and methods such as FIDO2 — eliminating the shared secret that attackers phish, spray, and stuff. But notice what a passwordless world leaves behind. Entitlements will still pile up on individual accounts. Accounts belonging to former employees will still be abandoned rather than deprovisioned. Admin rights needed for a two-week project will still be found, years later, quietly attached to someone's identity. A password policy, once set correctly, largely holds its value. A privilege model erodes daily unless it is actively managed and governed.

That is why I consider identity management and zero trust not to be two separate security solutions, but two components of a complete, layered defense. Zscaler seems to have solved a good deal of this (I have nothing to do with Zscaler, and I am not promoting them here). In a zero trust architecture, no user, device, or network location is implicitly trusted, and every request must be verified (Rose et al., 2020) — meaning that when another control fails, identity is the layer that bears the brunt of the damage. In practice, I am a strong believer in combining Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). RBAC is the right starting point: map users to the roles their jobs actually require, and audit regularly to ensure every entitlement is accounted for. But roles are static by nature. ABAC adds the dynamic layer — factoring in the posture of the user's device, the location they're connecting from, and the classification of the data they're trying to reach. Combined, the two produce an access model that is both auditable and adaptive: what a user can access changes with circumstances, rather than sitting as a standing entitlement waiting to be abused.

One note I feel strongly about: the road to passwordless runs through strong passwords. Until the transition is complete, the credentials we still depend on must be hardened — going passwordless doesn't excuse weak passwords in the meantime; it depends on surviving the meantime.

A stolen credential gets an intruder into the lobby. Unmanaged privilege is what escorts that identity down to the server room or the boardroom, where everything that matters is kept. So harden the entrance — then govern everything beyond it.

References

National Institute of Standards and Technology. (2025). Digital identity guidelines: Authentication and authenticator management (Special Publication 800-63B-4). https://doi.org/10.6028/NIST.SP.800-63B-4

Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero trust architecture (NIST Special Publication 800-207). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-207

Your University's AI Strategy Shouldn't Look Like Anyone Else's

 I've been deep in the architecture of my next book — an AI playbook for higher education — and I keep bumping into a problem that most of the "AI will transform the university" content quietly ignores: which university?

Because here's the thing nobody at the conference keynote wants to say out loud. A flagship R1 with a medical school, a regional state comprehensive, a 900-student faith-based college, and a system office are not four sizes of the same institution. They're four different organisms wearing the same word, "university," and handing them the same AI strategy is like handing a powerlifter, a marathoner, and a guy recovering from knee surgery the same workout plan. Technically, it's all exercise.

So one of the chapters I'm building is devoted entirely to this, and the more I work on it, the more I think it's the load-bearing wall of the whole book. The premise: institutional type isn't a demographic footnote. It determines your core AI problem — the thing that will actually eat you if you ignore it.

At an R1, the core problem is coordination. AI is already everywhere on that campus — the engineering college has three pilots, the med school signed something nobody in central IT has seen, and forty faculty have quietly wired models into their research workflows. The flagship doesn't need an AI adoption strategy; it needs an AI governance strategy, and a federated one at that, because the colleges of medicine, engineering, and law will run their own portfolios no matter what the provost's council decides. Central's real job is setting the floor — data protection, disclosure, human decision rights — and auditing against it. Not approving projects. That ship sailed before the committee formed.

At a regional comprehensive, the problem flips. It's capacity. These are the institutions that need AI's efficiency gains the most — advising caseloads north of 300:1, a financial aid office running on caffeine and heroics — and they have the least staff to implement anything. The cruel joke of this moment is that the institutions with the strongest per-dollar case for AI are the ones least equipped to deploy it. (This, incidentally, is the thesis of the whole book: higher ed needs AI most at exactly the moment it's least ready for it.)

At a small private, the problem is readiness. The data spine — the SIS, the CRM, the warehouse — is often held together with spreadsheets and institutional memory named Deborah. The upside is that a small private's cabinet can move in one board cycle, no faculty senate marathon required. The downside is identical: it can err in one board cycle. Speed without a data foundation just gets you to the wrong place faster.

And at a system office, the problem is authority: what gets decided centrally, what stays on campus, and who pays. Anyone who's watched a system-wide ERP project knows this fight. AI just runs it at higher velocity.

Two wrinkles from the research so far that deserve their own paragraphs, because almost nobody in the sector is talking about them.

First: if you're a public institution, your AI policy isn't entirely yours to write. A growing number of states have issued executive orders or legislation governing AI use in public agencies, and public universities are frequently in scope. Your regional comprehensive may already have obligations flowing downhill from the governor's office that your cabinet has never read.

Second, and this is the one that made me sit back from the keyboard: sunshine laws reach algorithms. A public university's AI-influenced admissions or financial aid decisions are potentially discoverable — public records requests, litigation — in ways a private institution's never will be. If a model is nudging who gets admitted or how aid is packaged at a state school, assume that someday a reporter or a plaintiff's attorney will get to look under the hood. That should change how you write vendor contracts and how you build audit trails, starting now, not after the request lands.

The chapter ends with a diagnostic — place your institution on the grid, then every subsequent chapter of the book closes with a "how this plays for you" note keyed to your archetype. Because a playbook that pretends the whole sector runs the same offense isn't a playbook. It's a poster.

More as the book develops. If you lead technology at one of these four kinds of institutions and your AI reality doesn't match my grid, I genuinely want to hear about it — the grid gets better when it gets argued with.  I think it would be a good idea to run a summary of all my chapters here and get genuine discussion going to reflect on and validate my ideas. 

Dr. Sam Kurien