Part 2 — Who Has Access to Your Business?
Protecting the Accounts That Hold the Keys
From Access to Protection
In Part 1, we looked at access as a form of business authority. We explored the difference between authentication and authorization, why trust and control are separate questions, how access accumulates over time, and how shared accounts can trade convenience for accountability. That foundation leads to a second question:
How should the business protect the accounts that carry the greatest authority?
Part 2 focuses on the accounts where authority is concentrated and on the methods used to protect them, including passwords, multifactor authentication, and passkeys. It also follows those accounts through role changes and departures, because stronger authentication only helps when the underlying access still belongs.
Protecting these accounts should make unauthorized access harder without losing sight of what the accounts are authorized to do. Stronger authentication matters most when it protects access the business has deliberately decided should exist.
Administrative Access Changes the Stakes
Not every account inside a business carries the same level of authority, and that difference matters because the amount of damage that can occur is often tied directly to what the account is allowed to do. Some accounts are designed for routine work and provide access only to the functions an employee needs. Others carry administrative privileges that allow the user to control the system itself, manage other users, change security settings, or alter how the application operates.
Administrative access deserves special attention because an administrator may be able to create or remove accounts, reset passwords, change permissions, install software, modify security settings, disable protections, access large amounts of information, connect additional applications, or remove other administrators. In some environments, an administrator can also change who owns the account or who has authority over it. That means an administrative account is not simply another login. It can become the place from which access to the rest of the system is controlled.
The consequences of a compromised account therefore depend heavily on the authority attached to that account. If a normal user account is compromised, the damage may be limited by the permissions assigned to the user. The attacker may be able to view certain files, send messages, or perform the same tasks the employee normally performs, but the account's boundaries may prevent the compromise from extending much further.
A compromised administrative account creates a different problem because the person controlling it may be able to change those boundaries. An attacker may create new accounts, grant additional permissions, change security settings, disable protections, or lock legitimate users out of the system. Instead of simply using the authority already attached to one account, the attacker may be able to expand that authority and create additional ways to remain inside the business.
That is why I do not think owners should look at access only in terms of whether someone can log into a system.
The more useful question is what that account can actually do after the person signs in.
Two employees may both have access to the same application, but one may be able to perform only routine tasks while the other can control the entire environment.
A social media account provides an easy example. The owner may retain administrative control over the page while an employee responsible for marketing receives permission to create, edit, and schedule posts. That employee can perform the assigned work without also receiving the ability to remove other administrators, change ownership settings, alter security controls, or take complete control of the account.
The same principle can apply to accounting software, cloud storage, websites, customer management systems, payroll applications, online banking, and other platforms. A person may need access to perform a particular function without needing the authority to control the system itself. Separating routine access from administrative control allows the business to give employees what they need without automatically giving them more authority than the job requires.
This becomes even more important when financial or operational decisions are involved. North Star includes the concept of separation of duties, which means dividing tasks and privileges among multiple people so that one person does not control every step of a sensitive process. In a larger organization, one person might enter a transaction, another might review it, and someone else might approve or release it. The separation creates another opportunity for an error, unusual activity, or fraudulent action to be noticed before it is completed.
A small business may not have enough employees to create that level of separation, and I think that reality needs to be acknowledged. In a five-person company, the owner may perform several functions that would be divided among multiple departments in a larger organization. The same person may review invoices, approve payments, manage payroll, maintain banking relationships, and administer important systems simply because there is nobody else available to take on those responsibilities.
The fact that a small business cannot always divide those duties does not make the principle irrelevant. It makes awareness more important because the owner needs to understand where authority is concentrated and what that concentration means. There is a significant difference between intentionally deciding that one person must handle several sensitive functions because of the size of the business and simply never realizing how much control that person has accumulated.
Consider a financial system where one employee can create a new vendor, change the vendor's payment instructions, approve an invoice, and release the funds. That employee may be completely trustworthy, but the account itself represents a significant concentration of authority. If the employee makes a mistake, if the credentials are stolen, or if someone gains control of the account, there may be very few barriers between the compromise and the movement of money.
The same issue can appear outside financial systems. One administrator may control the company website, email environment, cloud storage, customer records, and password resets. An outside technology provider may have remote access to multiple devices. A marketing contractor may control social media and advertising accounts that represent the company publicly. None of those arrangements is automatically inappropriate, because small businesses often need people to wear multiple hats and outside providers may require broad access to perform the work they were hired to do.
The concern is whether the owner understands how much authority has been concentrated in one person or account and whether that level of control is actually necessary. If one account can affect several important parts of the business, that account deserves more attention because a problem involving it can travel much further than a problem involving an account with narrower permissions.
This is where cybersecurity and traditional internal controls begin to overlap. Both are concerned with limiting how much damage one mistake, one compromised account, one dishonest action, or one misunderstood instruction can create. The small business may not always be able to divide every responsibility among several people, but it can still recognize where major authority exists and decide whether some additional safeguard is reasonable.
That safeguard does not have to be complicated. The business might require a second approval for a large payment, limit the number of administrators on an important system, require the owner to approve changes to banking information, review administrative accounts periodically, or document which employees and vendors have the ability to make significant changes. The aim is to keep one account from carrying more power than the business realizes without burying a small company under unnecessary layers of approval.
When an owner understands what administrative access actually allows, the question becomes much clearer. The business is not simply asking who can enter the system. It is asking how much one person, one account, or one compromised credential can affect before another person or another control becomes involved.
That answer tells the owner where the greatest concentration of authority exists and where an additional safeguard may be worth considering.
Passwords, MFA, and the Move Toward Passkeys
Passwords and multifactor authentication deserve attention because they are still among the most common ways businesses protect access to their systems. Both help answer an important question:
Is the person attempting to sign in actually who they claim to be?
That is the purpose of authentication, and strengthening authentication reduces the chance that someone can enter a business account simply because they obtained or guessed a password.
A password is one way of proving identity, but passwords carry weaknesses that business owners have been dealing with for years. People forget them, reuse them, choose predictable variations, share them with coworkers, save them in insecure places, or enter them into convincing phishing sites. A strong and unique password reduces some of those risks, particularly when it is managed properly, but the underlying system still depends on a secret that can be copied and entered somewhere else.
Multifactor authentication improves that situation by requiring another form of verification in addition to the password. Depending on the service, that may involve a code from an authenticator application, a physical security device, a biometric, or another method of proving that the person attempting to sign in possesses something beyond the password itself. If an attacker obtains an employee's password, that additional requirement may prevent the stolen credential from immediately becoming access to the account.
For a small business, that additional layer can make a meaningful difference. A compromised password associated with email, accounting, payroll, customer records, or another important system does not automatically have to become a compromised account. That is why MFA remains an important protection, particularly when passkeys or other stronger authentication methods are not available.
At the same time, authentication technology is continuing to evolve, and business owners are beginning to encounter another term more frequently: passkeys.
What Is a Passkey?
A passkey is designed to replace the traditional password rather than simply add another step after it. Instead of creating a password that both the user and the service rely upon as a shared secret, a passkey uses public-key cryptography. When the passkey is created, a cryptographic key pair is generated. The service keeps the public portion, while the private portion remains under the user's control on a device, security key, or passkey provider.
When the user later signs in, the service sends a challenge that can be successfully answered only by the corresponding private key. The user normally authorizes use of that passkey by unlocking the device in the same way they already do, such as with a fingerprint, facial recognition, device PIN, or another local verification method.
That distinction is important because the user is no longer typing a reusable secret into a website.
The private key is not sent to the website during authentication, and the service does not maintain a database containing the user's password that can later be stolen and reused somewhere else. FIDO, the standards organization behind passkeys, describes them as FIDO credentials built on public-key cryptography and designed specifically to provide phishing-resistant authentication.
For the small business owner, the underlying mathematics is probably less important than the practical difference. With a traditional password, someone who convinces an employee to type that password into a fake website may now possess the same secret the employee uses on the legitimate site. With a properly implemented passkey, the credential is associated with the legitimate website or application. A fake site cannot simply collect the passkey and replay it against the real service in the way it can with a password. Microsoft and FIDO both describe this binding to the legitimate service as one of the reasons passkeys are resistant to phishing.
That does not mean passkeys eliminate every possible account-security problem. A compromised device, weak account recovery process, poor device security, inappropriate authorization, or badly managed access can still create risk. Passkeys improve one important part of the problem: proving identity without relying on a password that can be copied, reused, or phished.
Why Passkeys Can Be More Secure Than Passwords and Some Forms of MFA
Traditional passwords create a recurring problem because the user has to know and enter the secret. Anything the user can type into the legitimate website can potentially be typed into a fraudulent one. Attackers have built entire industries around exploiting that weakness through phishing, credential theft, password reuse, and credential-stuffing attacks.
Some forms of MFA reduce that risk substantially, but not every form of MFA provides the same protection. A one-time code sent by text message or generated by an application adds another hurdle, but a convincing phishing site can sometimes persuade a user to enter both the password and the temporary code. The attacker then attempts to use those credentials against the real service before the code expires.
Passkeys approach the problem differently. Rather than relying on the employee to recognize whether the website is legitimate before entering a secret, the authentication process itself is cryptographically tied to the legitimate service. FIDO specifically identifies phishing resistance as a core property of passkey authentication and notes that passkeys also remove the password reuse problem because each credential is unique to the service for which it was created.
That shifts some of the burden away from the employee. For years, much of cybersecurity training has asked people to inspect links, recognize fake login pages, create complex passwords, remember which credentials belong where, avoid reuse, and notice when an authentication request does not look right. Those practices still matter, but passkeys can remove some opportunities for a simple human mistake to become a stolen credential because the technology performs more of the verification instead of depending entirely on the user to recognize the deception.
Not All Passkeys Are Stored the Same Way
Business owners should also understand that the word passkey does not describe only one storage arrangement. The two major categories are synced passkeys and device-bound passkeys.
A synced passkey can be made available across multiple devices through a passkey provider. For example, a person may create a passkey on one device and later have it available on another device connected to the same credential ecosystem. The synchronization is intended to make passkeys practical for everyday use because losing or replacing one device does not necessarily mean losing the ability to access every account.
For many small businesses, synced passkeys may provide a reasonable balance between stronger authentication and usability. Employees already move between phones, laptops, tablets, and replacement devices, and requiring a completely new credential registration every time hardware changes could make adoption unnecessarily difficult.
A device-bound passkey, by contrast, remains associated with a particular device or physical security key rather than being synchronized across a user's devices. Hardware security keys are a common example. The credential remains on that physical device and must be present when it is used.
Device-bound passkeys can provide a higher level of assurance because the credential does not move between devices through a synchronization service. That can make them particularly attractive for highly privileged accounts, regulated environments, or situations where the business places a very high value on limiting how and where the authentication credential can exist. The tradeoff is that the business must pay more attention to issuing devices, maintaining backups, replacing lost hardware, and establishing recovery procedures. FIDO recognizes both synced and device-bound passkeys and notes that the appropriate model depends in part on the required balance between usability, recovery, and security assurance.
This is an area where I think small businesses should avoid turning the discussion into an argument over which type is universally “best.” The better question is what level of protection and manageability makes sense for the account being protected.
A general employee account may have one set of needs, while the owner's primary administrator account may have another. An account controlling online banking, the company email environment, or other critical infrastructure may justify stronger controls than a system with relatively limited business impact. The choice should reflect the importance of the account and the consequences if its authentication method fails.
What Happens to the Fingerprint or Face Scan?
Biometrics can create understandable concern because people may hear that a passkey uses a fingerprint or facial recognition and assume that the biometric information is being transmitted to the website.
That is not generally how passkey authentication works. When a fingerprint, face scan, or device PIN is used to unlock a passkey, that verification occurs on the user's device. The website receives evidence that the authentication was successfully completed; it does not receive the person's fingerprint or facial image. FIDO specifically notes that biometric information remains on the device and is not sent to the remote service as part of the passkey authentication process.
That distinction is worth explaining to employees because otherwise the phrase “sign in with your fingerprint” can sound as though the company or website is collecting biometric information when the device is actually using its existing local security mechanism to authorize use of the credential.
How a Small Business Can Begin Using Passkeys
A small business generally cannot decide on its own that every application will begin using passkeys tomorrow. The website, software provider, bank, cloud service, or other application has to support passkey authentication.
That means implementation can begin with something much simpler than a companywide technology project: look at the important accounts the business already uses and determine which providers currently support passkeys.
I would begin with the accounts that carry the greatest authority or would create the greatest problem if compromised. The owner's primary email account is an obvious candidate because email is often used to reset passwords and recover access to other services. Administrative accounts for cloud services, accounting systems, websites, social media, financial platforms, and other important business services may deserve similar attention.
When a service offers a passkey option, the business should understand where that passkey will be stored. It may be stored and synchronized through an operating-system credential manager, through another passkey provider, or on a physical security key. That decision matters because it affects how the business will use the credential on additional devices, what happens when a device is replaced, and how access will be recovered if something is lost.
Recovery deserves particular attention because one of the easiest mistakes would be to adopt stronger authentication without deciding what happens when the employee loses the phone, damages the laptop, forgets the device PIN, leaves the company, or no longer has access to the account that synchronizes the passkey. A security control that nobody can recover from can create its own business-continuity problem.
For important accounts, the business should understand the provider's recovery process before relying entirely on the new authentication method. Where supported and appropriate, that may include registering more than one authorized authenticator or maintaining a securely controlled hardware security key as a backup. The exact approach will depend on the system and the sensitivity of the account.
Employee departures also need to be considered. A business does not want the only passkey controlling an important company account to exist solely within a former employee's personal credential environment. Business-managed accounts, administrative ownership, recovery methods, and offboarding procedures therefore remain important even when the authentication technology itself becomes stronger.
Passkeys strengthen authentication, but they do not eliminate the need to manage access. The business still has to decide who should hold the credential, where recovery authority resides, and what happens when the person's role changes or ends.
Stronger Authentication Still Does Not Fix the Wrong Authorization
That brings us back to the larger point of this section. A passkey can provide much stronger assurance that the person signing in is the legitimate holder of the account. It can reduce dependence on passwords, make phishing substantially more difficult, and potentially provide a simpler experience for employees because there may be no password to remember or type. What it does not determine is whether that person should still have the account.
A former employee can have a passkey protecting an account that should have been disabled. A contractor can use a phishing-resistant passkey while retaining administrator privileges that should have been removed months ago. An employee can sign in with one of the strongest authentication methods available and still possess access to information that no longer has anything to do with the employee's job.
In all of those examples, the authentication system may be working exactly as intended. The business has simply failed to reconsider the authorization behind it.
This is why I think passwords, MFA, and passkeys all need to be discussed as part of a larger access-management conversation rather than as isolated cybersecurity solutions. Passwords attempt to prove identity through a secret. MFA strengthens the identity check by adding another factor. Passkeys change the authentication model by replacing the reusable password with a phishing-resistant cryptographic credential.
Passwords, MFA, and passkeys represent different ways of improving confidence that the person attempting to enter is the person the business intended to authorize. The business still needs both sides of the access decision to work together: reasonable confidence in the identity at sign-in and confidence that the authority attached to that identity remains appropriate after the person is inside.
Otherwise, even the strongest authentication technology available can end up doing an excellent job of protecting access that should no longer exist.
When Responsibility Changes, Access Should Change
Access management begins when someone joins the business, but it cannot stop there. When a new employee starts, the business usually gives that person the accounts, applications, files, and permissions necessary to perform the job. Over time, however, responsibilities change. Employees are promoted, move into different positions, take on temporary assignments, or stop performing duties they once handled. Contractors finish projects, vendors are replaced, and outside professionals may no longer need the access they were originally given.
The permissions associated with those relationships should change as well. An employee who moves into a new position may need additional access, but that does not automatically mean everything associated with the previous position should remain. A contractor who was given administrative rights to complete a project may have no reason to retain those rights after the work is finished. When employment or another business relationship ends entirely, the access that existed because of that relationship should also come to an end.
That is the principle I would encourage a business owner to keep in mind:
Access should follow responsibility, and when the responsibility changes or ends, the access should change with it.
The principle itself is straightforward. Applying it consistently can be much harder, particularly in a small business where there may be no dedicated human resources department, information technology staff, or security team responsible for coordinating the process.
When someone leaves a small business, attention naturally goes to the things everyone can see. The owner may collect a building key, retrieve company equipment, notify payroll, update the employee roster, and tell coworkers that the person is no longer with the company. Those are familiar parts of an employee departure because the relationship between the employee and those physical business resources is obvious.
Digital access is much easier to overlook because it may be scattered across many different systems that were added over several years. The employee may have a company email account, access to shared cloud folders, credentials for accounting or scheduling software, permissions within a customer relationship management system, access to the company website or social media accounts, accounts with vendors, remote access to company computers, or applications that contain saved payment information. Company email may also still be connected to a personal phone or tablet, and files may have been downloaded to a laptop used outside the office.
The problem is rarely that the owner deliberately decides to leave all of that access in place. More often, the owner remembers the obvious systems and simply does not remember every application the employee has used. An account that was created two years earlier for a project that lasted three months may not immediately come to mind during an employee's last day. A website administrator account may have been created by a contractor rather than the owner. A cloud folder may have been shared directly with an employee years ago and never reviewed again. If the business has never maintained a clear record of access, removing it becomes an exercise in trying to remember where that person may have been given permission.
This is where process becomes more reliable than memory. North Star's policy guidance recognizes that businesses need clear expectations around how employees, contractors, and third parties use company technology and information. Policies such as Acceptable Use, Bring Your Own Device, Mobile Device Management, Remote Work, and Third Party policies help establish those expectations, but the underlying principle does not require a small business to build an enormous cybersecurity manual. A ten-person company may not need a hundred pages of policy language. It does need a repeatable way to grant, review, change, and remove access.
That process can begin when the employee is hired. Instead of simply creating accounts as someone remembers that they are needed, the business can identify which systems normally belong to the position, what level of access the person should receive, and who has authority to approve it. This creates a starting record of what the employee was given and why.
The same process should continue when the employee's responsibilities change. A promotion, transfer, or new assignment should not only trigger a conversation about what additional access is required. It should also create an opportunity to review what the employee already has. Some of those permissions may remain appropriate, while others may have belonged entirely to the previous job. Reviewing both the new and existing access prevents permissions from simply accumulating throughout an employee's career with the company.
The same lifecycle applies to contractors and outside providers. Temporary access should have a clear reason and an expected endpoint so the business knows when to reconsider it after the work is finished.
The departure process then becomes much more manageable because the business is not starting from memory. It already has some understanding of which systems the individual could access, what permissions were assigned, and which devices or applications may still contain company information. Email can be disabled or transferred appropriately, application accounts can be removed, administrative rights can be reassigned, shared passwords can be changed where necessary, remote access can be revoked, and company data on authorized personal devices can be addressed according to whatever policies the business has established.
Offboarding should also confirm that no critical company account depends on a departing person's personal email address, phone number, or recovery method. If account ownership or recovery is tied to the person leaving, that control should be transferred before the access is disabled.
Onboarding and offboarding are therefore more than administrative tasks. They are opportunities to verify that the business maintains control of the systems and accounts on which it depends, including who can recover an account and who has authority to grant or remove access when responsibilities change.
Consistency is what makes this manageable. The business does not need an elaborate enterprise system to begin. A documented onboarding and offboarding checklist may be enough to ensure that the same important questions are asked every time. Which systems should this person receive? What level of permission is appropriate? Who approved it? What company information may exist on personal devices? What access changes when the job changes? What must be disabled or transferred when the relationship ends? Who is responsible for verifying that those actions were completed?
Once those questions become part of a repeatable process, the business is no longer depending on someone to remember every account during a busy Friday afternoon when an employee leaves. The work of identifying access began when the relationship began, continued as responsibilities changed, and provides the business with a much clearer path for removing or transferring that access when the responsibility comes to an end.
Access Does Not End at the Account
At this point, we have looked at who receives access, how much authority that access can provide, how authentication can be strengthened, and why permissions should change when responsibilities change. But accounts are only one part of the access environment.
The device used to reach the account matters too. So do the contractors, vendors, and outside providers that may operate inside the business's systems. Someone also has to be responsible for seeing the whole picture, because access decisions can become fragmented when one person manages employees, another manages technology, and a third manages vendors.
Part 3 will bring those pieces together. We will look at personal devices and remote work, contractor and vendor access, responsibility for access management, and what a practical access review should actually accomplish for a small business.
References
America’s SBDC North Star Cybersecurity Program. Definitions Document, FY 2026 Supplemental Training Materials. Used for terminology and concepts related to authentication, authorization, multifactor authentication, least privilege, separation of duties, and administrative access.
America’s SBDC North Star Cybersecurity Program. Cybersecurity Best Practices, FY 2026 Supplemental Training Materials. Used for guidance related to authentication, access-control reviews, protection of critical systems, administrative privileges, and assignment of cybersecurity responsibilities.
America’s SBDC North Star Cybersecurity Program. Cybersecurity Policy Definitions, FY 2026 Supplemental Training Materials. Used for policy concepts related to onboarding, offboarding, acceptable use, remote access, personal devices, third-party access, and the management of employee and contractor access.
National Institute of Standards and Technology. NIST Special Publication 800-63B-4: Digital Identity Guidelines — Authentication and Authenticator Management. July 2025. Provides current federal guidance on passwords, authenticators, authentication assurance, phishing-resistant authentication, and authenticator management. NIST Computer Security Resource Center
National Institute of Standards and Technology. NIST Special Publication 800-63-4: Digital Identity Guidelines. July 2025. Provides broader guidance on digital identity, authentication, enrollment, authenticator management, and identity lifecycle considerations. NIST Computer Security Resource Center
FIDO Alliance. Passkeys. Provides technical and practical guidance on passkey authentication, public-key cryptography, phishing resistance, and the distinction between synced and device-bound passkeys.
FIDO Alliance. Replacing Password-Only Authentication with Passkeys in the Enterprise. Provides implementation guidance for organizations adopting passkeys, including credential deployment, security keys, recovery, usability, and enterprise account-management considerations.
Microsoft. Passkey (FIDO2) Authentication with Microsoft Entra ID. Microsoft Learn. Provides implementation guidance for synced and device-bound passkeys, including platform compatibility and the use of passkeys as phishing-resistant authentication methods. Microsoft Learn
Microsoft. Register a Passkey with a FIDO2 Security Key. Microsoft Learn. Explains the use of device-bound passkeys stored on physical security keys, including their application for privileged users and higher-risk accounts. Microsoft Learn
National Institute of Standards and Technology. The NIST Cybersecurity Framework (CSF) 2.0. Provides a broader framework for managing cybersecurity risk, including identity management, access control, governance, protection, and recovery.
Part 2 — Who Has Access to Your Business? Protecting the Accounts That Hold the Keys
By Manzel McGhee Jr., ASBC® | Abilene SBDC
