Multi-factor authentication is one of the most valuable security controls a business can implement.
It is also not an identity security strategy.
MFA makes it harder for an attacker to use a stolen password. That matters. But it doesn’t answer some equally important questions:
Who has access to your systems?
What can they access?
Who has administrative privileges?
Which accounts are no longer needed?
What happens to access when someone changes roles or leaves?
And if an account is compromised, how much damage can that account actually cause?
For many small businesses, identity has effectively become the new security perimeter. Employees work remotely, applications live in the cloud, and company resources are accessed from networks the business doesn’t control.
Protecting the network is still important.
But increasingly, protecting who can access what is just as important.
Start With the Account
Think about what a single employee account might provide access to.
Email.
Cloud storage.
Customer information.
Internal documents.
Financial applications.
Communication platforms.
Administrative systems.
A compromised password isn’t necessarily the real problem.
The real problem is what that password unlocks.
This is why identity and access security should be approached as more than password complexity and MFA.
The objective is to limit both the likelihood of unauthorized access and the damage that access could cause.
MFA Is a Control, Not a Complete Solution
MFA adds another verification requirement beyond a password.
That significantly improves account security because obtaining a password alone may no longer be enough to authenticate.
But MFA doesn’t fix poor access decisions.
Imagine an employee has access to ten systems but only needs four to perform their job.
Adding MFA protects authentication to that account.
It doesn’t explain why the employee has access to the other six systems.
Likewise, MFA doesn’t automatically solve:
- Excessive administrative privileges
- Dormant accounts
- Shared accounts
- Poor employee offboarding
- Weak recovery procedures
- Inappropriate permissions
- Unmanaged service accounts
- Privilege accumulation over time
These are identity problems.
They require identity controls.
The Principle of Least Privilege
One of the most useful concepts in access security is also one of the simplest:
Give people the access they need to perform their work — and no more.
This is the principle of least privilege.
It sounds obvious.
In practice, access tends to accumulate.
An employee joins the company and receives access to several systems.
Six months later, they take on another responsibility and receive additional permissions.
A year later, they move to another role.
New access is granted.
Old access isn’t always removed.
Eventually, the employee may have significantly more access than their current job requires.
This is sometimes called privilege creep.
The employee hasn’t necessarily done anything wrong. The organization simply hasn’t maintained access as responsibilities changed.
That becomes a security problem if the account is compromised.
The attacker inherits the permissions of the account they control.
Reducing unnecessary permissions therefore reduces the potential impact of account compromise.
Administrative Accounts Deserve Different Treatment
Administrative access creates considerably more risk than ordinary user access.
An administrator may be able to install software, create accounts, change security configurations, access sensitive information, or modify other users’ permissions.
That makes administrative credentials particularly valuable to attackers.
Businesses should know exactly:
- Who has administrative access
- Why they have it
- Which systems it applies to
- Whether it is still necessary
- Whether administrative activity is logged
- Whether normal work is being performed using privileged accounts
Where practical, everyday activity and administrative activity should be separated.
Someone who needs administrative privileges occasionally doesn’t necessarily need to browse the web, read email, and perform ordinary work using an administrator account all day.
The question isn’t:
“Do we trust this employee?”
The question is:
“Does this account need this level of access?”
Those are very different security questions.
Shared Accounts Create Blind Spots
Shared credentials are convenient.
They’re also difficult to govern.
If five employees use the same account and something happens under that account, determining who performed the action becomes harder.
Password changes become more complicated.
Offboarding becomes more complicated.
Accountability becomes weaker.
And when someone leaves the organization, the business must remember every shared credential that person knew.
Whenever possible, individual users should have individual identities.
Permissions can then be assigned based on what each person actually needs.
That improves both security and visibility.
Offboarding Is a Security Control
One of the simplest questions I would ask during an identity review is:
What happens to someone’s access when they leave the company?
If the answer depends on someone remembering to manually disable a few accounts, there’s room for improvement.
Employee access can exist across many places:
Microsoft 365 or Google Workspace.
VPNs.
Cloud platforms.
Customer relationship management systems.
Accounting software.
Password managers.
Internal applications.
File-sharing platforms.
Remote-access tools.
Third-party SaaS applications.
Removing an employee from one system doesn’t necessarily remove access everywhere else.
A documented offboarding process reduces the likelihood of forgotten accounts remaining active.
The same concept applies when employees change roles.
Access should follow business need, not employment history.
Dormant Accounts Matter
Unused accounts are easy to forget because they aren’t creating operational problems.
That’s precisely why they can survive for years.
An account belonging to a former employee, contractor, test environment, or discontinued service may still have valid credentials and permissions.
From an attacker’s perspective, an account doesn’t become harmless simply because nobody legitimate is using it.
Regular access reviews should identify accounts that are inactive, unnecessary, or no longer associated with a legitimate business purpose.
If an account doesn’t need to exist, removing it is often better than finding another way to protect it.
Authentication Recovery Is Part of Authentication Security
Businesses frequently strengthen the login process while overlooking account recovery.
That’s a mistake.
If an attacker can bypass strong authentication through a weak password-reset or recovery process, the strength of the original authentication method matters considerably less.
Recovery methods should therefore be reviewed alongside MFA.
Consider:
Who can reset a password?
How is someone’s identity verified?
Can MFA methods be reset?
Which email addresses or phone numbers are used for recovery?
Can help desk or administrative staff override authentication controls?
Are recovery actions logged?
A security control is only as strong as the paths available around it.
Service Accounts and Non-Human Identities
Not every account belongs to a person.
Applications, automated processes, scripts, scheduled tasks, and integrations may also require credentials.
These accounts are easy to overlook because nobody logs into them every morning.
They can also be highly privileged.
Service accounts should have a defined purpose, appropriate permissions, controlled credentials, and an identifiable owner.
If nobody knows what an account does but everyone is afraid to disable it, that’s already useful information about the organization’s identity management.
Access Should Be Reviewed, Not Just Assigned
Many organizations have a process for granting access.
Far fewer have an equally mature process for reviewing it.
Access decisions shouldn’t necessarily last forever.
Periodically ask:
Does this person still need this application?
Do they still need this permission?
Does this administrator still require administrative access?
Are there accounts nobody recognizes?
Are former employees completely removed?
Are contractors still active?
Have new applications appeared outside the normal approval process?
The purpose isn’t bureaucracy.
It’s preventing yesterday’s access decisions from quietly becoming tomorrow’s vulnerabilities.
Logging Makes Identity Visible
Access controls determine what someone can do.
Logging helps determine what they did.
Authentication logs can reveal failed logins, successful logins, account changes, administrative activity, lockouts, and other behavior worth investigating.
But a failed authentication isn’t automatically an attack.
Someone might mistype a password.
A saved credential might be outdated.
A legitimate application might repeatedly attempt authentication with an old password.
Context changes the meaning.
One failed login from an employee’s normal workstation during business hours is different from hundreds of failures across multiple accounts followed by a successful authentication from an unexpected source.
This is why identity security and security monitoring increasingly overlap.
The objective isn’t simply to prevent unauthorized access.
It’s also to have enough visibility to recognize when something unusual is happening.
What Should an Identity and Access Review Examine?
For a small business, an identity review doesn’t need to become a massive enterprise IAM project.
Start with practical questions:
Accounts: Who has accounts, and do they all still need them?
Authentication: Where is MFA enabled, and where isn’t it?
Privileges: Who has administrative access?
Permissions: Do users have more access than their roles require?
Lifecycle: How are accounts created, changed, and removed?
Recovery: Can strong authentication be bypassed through weak recovery procedures?
Service accounts: Which non-human identities exist, and what can they do?
Logging: Can important authentication and account activity be investigated?
Those questions alone can uncover significant exposure.
Identity Security Is About Containing Damage
It’s tempting to think about cybersecurity entirely in terms of keeping attackers out.
That’s unrealistic.
Passwords will occasionally be exposed.
Employees will occasionally click things they shouldn’t.
Devices will occasionally become compromised.
Security should account for that possibility.
If one employee account is compromised, good identity controls can limit what happens next.
The attacker encounters MFA.
The account has limited permissions.
Administrative access is separated.
Sensitive systems require additional controls.
Authentication activity is logged.
Suspicious behavior can be investigated.
Each layer reduces either the probability or potential impact of compromise.
That’s defense in depth applied to identity.
Start With Who Can Access What
MFA should absolutely be part of a small business security strategy.
But don’t stop there.
The more useful questions are:
Who has access?
What can they access?
Why do they have that access?
How is that access protected?
Would we know if it were abused?
If those questions can’t be answered confidently, there is more identity work to do.
Good identity security isn’t about making authentication inconvenient.
It’s about ensuring that access is intentional, limited, protected, visible, and removed when it is no longer needed.