Nonprofit password management usually gets attention only after something goes wrong. For most organizations, the first sign is a locked login at the worst possible moment, such as the morning a major grant is due, when nobody can say who created the account, who still has access, or where the second authentication code is going.
It is 9:20 on a Wednesday, and the application is due Thursday at noon.
The development director opens the federal grants portal to upload the final budget. The system asks for a code. The code goes to a phone number she does not recognize.
She searches her email for the account setup. The login was created fourteen months ago by a program manager who has since left, using her personal email address. The password, someone says, might be in a spreadsheet called “Logins 2022” on the shared drive. The spreadsheet is there. The password in it no longer works.
The treasurer remembers that the volunteer grant writer from last spring had access. The volunteer says she has not logged in since June, but she still has the password saved in her browser.
Someone else points out that the organization’s federal registration may have come up for renewal. Nobody knows when it expires, or who receives the reminder.
The director finally gets back in through a recovery process that takes most of the afternoon. When she does, she finds something she did not expect: three users on the account who do not work at the organization anymore, one of them with administrator rights.
It Is One Failure With Two Faces
The scene above contains two problems that look different but have the same cause.
The lockout. Nobody currently at the organization can reliably get in. That risks missed deadlines, lost funding, and expensive scrambling.
The exposure. People who should not have access still do. That risks unauthorized changes, stolen information, and fraud.
Both exist because nobody owns the list of who has access to what. When access is shared, undocumented, or tied to personal email addresses and phones, an organization simultaneously makes it harder for its own staff to get in and easier for outsiders to stay in.
What Sits Behind a Grant Login
It is easy to think of a grant portal as a place to upload documents. The accounts behind these systems hold much more.
A federal entity registration, for example, contains the organization’s legal name, employer identification number, tax information, and banking details used to receive payments. Federal agencies and many states and foundations require nonprofits to maintain these registrations to apply for or receive funds.
Applications themselves often include financial statements, board lists, salary information, program data, and descriptions of the people the organization serves. Reporting portals can hold payment requests and draw-down information.
An attacker or a former insider who reaches those accounts can change bank details to divert payments, withdraw or alter an application, read confidential financial information, or impersonate the organization to a funder.
This is not theoretical. The General Services Administration, which runs the federal registration system, has acknowledged attempts to fraudulently change entities’ bank account information in that system. It responded by requiring multifactor authentication through Login.gov and by notifying entity administrators whenever bank account details change.
How the Federal Systems Expect Access to Work
The government’s own design points toward the practices most nonprofits are missing.
Federal award registration uses Login.gov for sign-in, and multifactor authentication is required. Each person who needs access is supposed to have their own account, and the entity’s administrator assigns roles inside the system. Guidance for registrants says login credentials should not be shared, and notes that Login.gov accounts are designed for individual use.
Applications through the federal grants system follow a similar structure. A designated point of contact controls who holds the authorized representative role that allows a person to submit on the organization’s behalf.
Practitioner guidance for administrators of these registrations is consistent: set up two multifactor methods so one lost phone does not lock everyone out, do not approve access for anyone you do not know and cannot explain, and review the user list regularly, promptly removing people who have left or changed roles.
Registrations also expire. They must be renewed every year, and the system sends reminders to the contacts on file. If those contacts are former staff, the reminders go nowhere.
The takeaway is simple. The systems are built for named individuals with defined roles. Sharing one login around the office works against that design and removes the protections it provides.
The Cost of the Shared Password
An earlier article in this series described why shared logins are an accountability problem as much as a security one, and that applies directly to grant systems.
When several people use one login, there is no way to say who submitted an application, who changed a figure, or who altered a bank account. If something goes wrong, every person who knew the password is a possible explanation and none can be ruled out.
A shared password also cannot be taken back from anyone. When someone leaves, the only way to end their access is to change the password for everyone, which means redistributing it, which rarely happens. The old password lives on in browsers, spreadsheets, and memory.
And a shared login tends to be tied to one person’s phone or email, so the organization’s access depends on that individual staying employed and keeping the same number.
Federal Rules Treat This as Internal Control
For organizations that receive federal awards, access control is part of a regulatory duty, not only good practice.
The federal Uniform Guidance, the rules governing federal grants, requires recipients and subrecipients to establish, document, and maintain effective internal control over each award. It also requires them to take reasonable cybersecurity and other measures to safeguard protected personally identifiable information and other sensitive information. A 2024 revision made the reference to cybersecurity explicit.
A nonprofit that cannot say who has access to its award systems, or that lets a former employee retain administrator rights, will find it hard to demonstrate effective internal control to an auditor or program officer.
Funders beyond the federal government increasingly ask the same questions. As discussed in earlier articles in this series on board oversight and cyber insurance, evidence of documented security practices is becoming part of grant applications, renewals, and insurance underwriting.
What CISA and NIST Say
Federal cybersecurity guidance converges on a few basic principles that fit this problem directly.
CISA’s Cross-Sector Cybersecurity Performance Goals, a voluntary baseline designed to help organizations with limited resources prioritize, call for unique, separate credentials for each user and service, with no reuse of passwords across accounts. They call for a defined, enforced process to revoke credentials for departing staff, including contractors and vendors, no later than the day they leave. They call for multifactor authentication, and they recommend that credentials be stored securely, such as in a password manager. CISA’s public awareness campaign also recommends using a password manager to create and store unique passwords for every account.
NIST’s security controls catalog says account management processes should be aligned with personnel termination and transfer processes, so that ending someone’s employment automatically triggers review of their accounts. Its termination control also requires retrieving security-related property, which NIST describes as including hardware authentication tokens, keys, and identification cards.
None of this requires a large IT department. It requires a small number of consistent habits.
A Practical Setup for a Nonprofit
A nonprofit can bring grant system access under control with a short, structured effort.
Inventory every portal. List every grant-related system: federal registration and application systems, state portals, foundation and corporate giving portals, payment and reporting systems, and any consultant-managed platforms. For each, record who administers it, who has access, what email and phone are tied to it, and when any registration or certification expires.
Use organizational emails, not personal ones. Registrations should be tied to an organization-controlled email address, preferably a role-based mailbox monitored by more than one authorized person, so the departure of one employee does not cut off recovery or reminders. A role-based mailbox is for receiving notices and recovery messages. It is not a license to share a password.
Name at least two administrators. Every critical system should have two named, accountable administrators, so there is always a backup. Document who they are and review the list when roles change.
Give each person an individual account. Use the systems’ own user and role features. Assign the least access each person needs for the task, and no more.
Control the authentication devices. Multifactor codes should not depend on one employee’s personal phone. Use methods the organization can manage, register more than one method per administrator, and store recovery codes in a secure place the organization controls.
Use a business password manager for credentials that must be shared. Some foundation portals and older systems offer only one login. For these, a business-grade password manager with access controls and logging replaces the sticky note and the spreadsheet. It lets the organization grant and remove access to a credential without anyone memorizing or retyping it, and it records who used it.
Add the portals to the offboarding checklist. When any staff member, volunteer, or consultant leaves, a documented step removes their access to every grant system on the inventory, the same day.
Review quarterly. Once a quarter, compare each portal’s user list against the current roster. Remove anyone who should not be there.
Test before deadlines. Two weeks before a major submission, log in and confirm that the intended submitter can get all the way to the upload screen. Finding a problem with ten days to spare is a minor annoyance. Finding it the morning of is a crisis.
Name One Owner for the Whole List
Almost every failure in the opening scene traces to the same gap: each system had a creator, and nobody had the whole picture.
Assign one person, such as an operations director, a development director, or an outside managed IT services partner working alongside them, to own the access inventory. That owner keeps the list current, runs the quarterly review, confirms that two administrators exist for each critical system, and puts every renewal date on a shared calendar with a reminder well ahead of time.
The owner should also receive the alerts. When cybersecurity monitoring flags a login from an unusual location, a new user added to a portal, or a change to payment details, the owner can act the same day. For a nonprofit with a small team, this is often the difference between catching a problem in an hour and finding it after a payment is lost.
Handle Volunteers and Outside Grant Writers Carefully
Many nonprofits rely on volunteer or contract grant writers who contribute for a season. Their access needs to be deliberate.
Give them their own accounts, not the organization’s login. Limit them to the specific systems and roles they need. Set an end date when you grant access, and remove it when the work is done. An earlier article in this series on departing volunteers described how access tends to outlast the relationship, and grant writers are a common example.
If a consultant manages submissions on the organization’s behalf, put the arrangement in writing: who administers the accounts, where credentials are stored, and what happens to access when the engagement ends.
What to Do If Something Looks Wrong
If an organization finds a user it does not recognize, an unexpected change, or a lockout it cannot explain, a clear sequence helps.
Remove or suspend unknown users and change administrator authentication right away. Review recent changes, especially to bank account details, contact information, and authorized representatives. Contact the system’s support desk and, for federal registrations, the federal service desk to report suspected unauthorized activity. Notify the funder or program officer if an application or award could be affected. Preserve logs and screenshots, and tell the board chair and, if appropriate, your insurer.
Speed matters most when banking information is involved, since a diverted payment is far easier to stop before it is sent.
What This Means for Miami and South Florida Nonprofits
South Florida nonprofits face several local conditions that raise the stakes.
Many local organizations depend on a mix of federal, state, county, and foundation funding, which means a larger number of portals, each with its own login and renewal cycle. The more systems an organization uses, the more likely one has slipped through the cracks.
Hurricane response and recovery bring surges in funding opportunities with short deadlines. Organizations that need to apply quickly find out whether their credentials work at the worst possible moment.
Many nonprofits here operate with small teams, part-time administrators, and heavy reliance on volunteers and outside consultants, which makes undocumented, shared access common.
And turnover is high. Program staff come and go, and an account created by someone who left two years ago is easy to forget until it fails.
Ask Your IT Provider Questions Like These
Do we have a complete inventory of every grant, funder, and payment portal, with the administrators, users, and expiration dates for each?
Are all of those accounts tied to organizational emails and to authentication methods the organization controls, not individuals’ personal phones?
Does every user have an individual account with the minimum role needed, and are there any shared logins?
Do we have a business password manager for credentials that cannot be individualized, and are recovery codes stored securely?
Does our offboarding checklist remove access to every grant system the same day someone leaves?
When did we last compare each portal’s user list against our current staff and volunteers?
If your IT provider cannot answer these clearly, the next time you need to log in may be the first time you find out.
The Deadline Will Not Wait for the Recovery Process
Grant systems fail quietly. The login that worked last year still sits in a browser, the registration that expires in November still sends its reminder to someone who left, and the user list still includes names no one remembers adding.
Fixing that takes a few hours of inventory and a handful of habits, and it protects both the funding the organization depends on and the information it holds.
ITva Technologies provides managed IT and cybersecurity services for nonprofits across Miami-Dade and Broward, with specific experience helping mission-driven organizations bring grant and funder systems under documented, accountable access control.
Our managed IT services include building the inventory of portals and users, setting up business password management and shared mailboxes, and adding every system to a repeatable offboarding checklist.
Our Microsoft 365 services help nonprofits manage identity, multifactor authentication, and access in one place, so administrators have a clear view of who can reach what.
Our cybersecurity services include phishing-resistant authentication, monitoring for unusual sign-ins and account changes, and the documentation that supports your internal control obligations to funders.
If your organization has never listed who has access to each grant system, that is worth doing before the next deadline.
Schedule a free grant portal access review with ITva.
We will inventory your funder systems, identify the accounts and users that should not exist, and set up a process that keeps the list accurate.
Because the login worked fine until the morning it mattered.
The time to find out who has it is before then.
Frequently Asked Questions
Why is a shared grant portal password a problem?
A shared login makes it impossible to tell who submitted an application or changed information, cannot be taken back from someone who leaves without changing it for everyone, and often depends on one employee’s personal email or phone. Federal registration systems are designed for individual accounts with defined roles.
What does the federal registration system require for access?
It uses Login.gov for sign-in with multifactor authentication required. Each person who needs access should have their own account, and the entity’s administrator assigns roles. Registrations must also be renewed annually, with reminders sent to the contacts on file.
Can someone fraudulently change our bank details in a federal registration?
Federal officials have acknowledged attempts to change entities’ bank account information in the registration system. In response, the system requires multifactor authentication and notifies entity administrators when bank account details change, which makes it important that those administrators are current and monitoring their email.
Do federal grant rules require us to control access to award systems?
The Uniform Guidance requires recipients and subrecipients to maintain effective, documented internal control over each award and to take reasonable cybersecurity and other measures to safeguard protected personally identifiable information and other sensitive information. Controlling who can access award systems is part of demonstrating that.
What should we do about portals that only allow one login?
Store the credential in a business password manager that controls who can use it and records access, and keep the multifactor authentication device and recovery codes under organizational control, not on an individual’s personal phone.
How often should we review who has access?
At least quarterly, and immediately whenever a staff member, volunteer, or consultant leaves or changes roles. Each portal’s user list should be compared against your current roster, and anyone who should not be there removed the same day.