How to Audit Authentication & Password Controls (Part 1)

When it comes to system security, authentication is one of the most fundamental IT general controls.

But while most auditors know the basics - check the password policy, confirm it matches the system settings; not everyone takes the time to understand the context in which authentication actually works.

This newsletter is part one of a two-part series where we’ll break down how to audit authentication and password parameter.

Starting with understanding the control.

Let’s Start with the Basics: What is Authentication?

Authentication is the process by which a system verifies that the identity provided truly belongs to the user trying to gain access. It’s the front door to your environment and how that door is locked matters a lot.

But not all doors are the same. And not all authentication controls work the same way.

That’s why as an auditor,

Your first step is to understand how authentication is designed for the application you’re auditing.

Three Types of Authentication Scenarios

From my experience, I’ve seen authentication controls fall into one of three categories. Knowing which one you're dealing with will define how you test it.

1. Applications Authenticated via Active Directory (AD)

These are applications where users can access the system only from the corporate network through an Active Directory login. They can’t log in directly through the internet.

In this case, you just don’t test the password and authentication settings for the application itself.

First, you test the Active Directory password settings, because that’s where authentication is happening.

But here’s the catch:

Most auditors only compare AD password settings with the company’s policy.

You need to go one step further. Ask yourself: Is the password policy itself strong enough for today’s threat landscape?

For example, if the policy requires 8-character passwords, but current standards recommend 12–14 characters, that’s worth flagging to management - even if it technically “passes” the test.

You don’t need to raise an exception. But you do need to bring it to the table and let management make the decision with full awareness.

2. Applications Accessible Without a Corporate Network

These are applications that can be accessed over the internet, without needing to log into the corporate VPN.

In this case, the application itself handles authentication, and you need to:

• Check the password parameters configured within the application
• Compare them against the organization’s security policy
• Ensure alignment with standards like password complexity, length, expiration, and lockout thresholds, password reuse and account lockout to name a few.

Again, alignment with policy is the baseline but awareness of current security best practices gives your audit depth and relevance.

3. Applications Controlled by a Service Organization

These are SaaS or third-party platforms where you don’t control the authentication settings. The vendor does.

Here, your approach changes:

• Ask for the SOC 1 or SOC 2 report for that application
• Look for password and authentication controls in the report
• Verify that the service organization’s controls align with your organization’s requirements

This is where vendor risk management and reliance on third-party controls becomes a key part of your audit thinking.

Takeaway

The goal of this week’s newsletter is simple:

Don’t just check a box. Understand how the application authenticates users and where the control lives.

Once you know that, you’ll know how to test it.

Next week in Part 2, we’ll talk about:

• What questions to ask during walkthroughs
• How to prepare for a meaningful discussion with control owners
• And how to assess design effectiveness based on real-world scenarios

Hope this was helpful. Let me know if you’ve worked with any of these three authentication types and how you tested them.

Until next time, Chinmay Kulkarni