MissionDefend Blog

Home Articles Get your free assessmentComing soon

Tag: volunteers

  • One Login, Five People, Fifteen Years: The Church Office Computer

    One Login, Five People, Fifteen Years: The Church Office Computer

    There’s a computer in the church office. It sits on the desk near the window, and it has been there long enough that nobody remembers who bought it.

    Everyone uses it. The office administrator, obviously. The treasurer on Thursday mornings. The youth director when the church laptop is somewhere else. Two volunteers who take turns doing the bulletin. The pastor, when he needs to print something.

    They all sign in the same way, because there is only one way to sign in. The account is called Office, and the password is on an index card under the keyboard:

    Office / FirstChurch2019! (giving site + email — same one)

    Nobody did anything wrong here. This is what happens when five people share one machine, none of them work full time, and the alternative — remembering who has which password — sounds like more administration than anybody has room for. The card under the keyboard is a reasonable solution to a real problem.

    It’s also the single point where a small organization’s whole digital life is exposed, and the fix costs nothing but an afternoon.

    What “one login” actually costs you

    Four specific things, and it’s worth being concrete about each, because “shared accounts are bad practice” is abstract enough to ignore.

    You can never tell who did what. A file is deleted, a giving record is edited, a check register doesn’t balance. The computer’s own records say Office did it, which is true and useless. There’s no way to reconstruct a mistake, no way to clear someone who’s been quietly suspected, and no way to answer an auditor or an insurer who asks a reasonable question. The absence of an answer is worse for the innocent than the guilty — in a small church, the not-knowing lands on everyone.

    One bad moment exposes everything anyone has ever opened. If a volunteer downloads the wrong attachment, whatever runs next is running as Office, and Office can reach every file, every saved password, and every signed-in website that anyone has ever used on that machine. There are no walls inside a shared account, because a shared account is one room.

    A person who left in 2021 still has the keys. The volunteer who did the bulletin for two years and moved to another state knows the password. So does her husband, probably, and anyone she wrote it down for. Nobody has changed it, because changing it means telling five people, and one of them is always on vacation. Every departure since the card was written is still a person who can get in.

    And the browser hands over the money. The biggest one, the least understood, and it needs its own section.

    A signed-in browser is a signed-in everything

    When you use Chrome, Edge, Safari, or Firefox, everything about “you” — your saved passwords, your bookmarks, your history, and the small files that keep you logged in — lives in something called a browser profile. It’s the browser’s version of a user account. On a shared computer with one login, there is one profile, and everybody is inside it.

    Two things in that profile matter enormously.

    Saved passwords. Every time someone clicked Save password — for the giving platform, the bank, the church management system, the email account, the domain registrar — the browser filed it away. Anyone sitting at that desk can open the browser’s password screen and read them in plain text, or simply visit the site and let it fill itself in.

    Session cookies. When you sign in to a website, the site gives your browser a small token that says this browser is already logged in, don’t ask again. That’s why you don’t retype your bank password every morning. It’s also why a machine that nobody is currently sitting at is still, from the website’s point of view, signed in.

    Put those together and the practical situation is this: anyone who can get to that keyboard, or anything that runs on that computer, can reach your giving platform and your bank without ever knowing a password. Not by guessing. By clicking the bookmark.

    That is the actual risk on a shared office computer. Not that someone will crack a code — that no code is being asked for.

    Separate accounts on the same machine, at no cost

    You do not need a new computer, new software, or a budget line. Both Windows and macOS have supported multiple user accounts on one machine for decades, and it’s free.

    Give each regular person their own account. Not a personal computer — a personal account on the shared computer. Their own desktop, their own files, and critically, their own browser profile with their own saved passwords. When the treasurer signs out, her session ends. When the bulletin volunteer signs in, she sees her own world and not the church’s bank account.

    Four or five accounts is normal for a church office, plus a Guest account for the occasional person who just needs to print, with nothing saved in it.

    Make the everyday accounts non-administrator. An administrator account is one that’s allowed to install software and change the machine’s settings. The everyday accounts don’t need that power, and taking it away means that when something malicious tries to install itself, it hits a wall and asks for a password that the person sitting there doesn’t have.

    Create one administrator account with a strong unique password, write it down, and put it where the pastor and the treasurer can both reach it — a sealed envelope in the safe is genuinely fine. Don’t use it for daily work; it exists for installing things and fixing things.

    That single change, more than any product you could buy, is what stops an ordinary bad click from becoming a bad week.

    Three settings and one habit

    With the accounts in place, four things remain. None takes long.

    Turn on the automatic screen lock. Both operating systems will lock the screen after a set idle period and ask for the password to come back. Ten or fifteen minutes is right for a church office. This is the control that handles the real-world scenario — not a break-in, but the office being empty for twenty minutes during a funeral while contractors and members of the congregation walk past an unlocked desk.

    Turn on full-disk encryption. Encryption scrambles everything stored on the machine so that it’s unreadable without the password. On Windows this is BitLocker; on Windows Home the same protection appears as device encryption, which switches BitLocker on for you. On Mac it’s FileVault. All are built in and free.

    Without it, a stolen computer is an open filing cabinet — someone can pull the drive out and read every file on it without knowing any of your passwords. With it, a stolen computer is a brick. Newer Macs encrypt storage automatically, but FileVault is what ties decryption to somebody actually knowing the login password, which is the part that matters. On Windows, look under privacy and security settings for device encryption or BitLocker and confirm it’s on — on a machine signed in with a local account rather than a Microsoft account, it often isn’t.

    One warning that Apple states bluntly and that applies to both systems: if you turn on encryption and then lose both the password and the recovery key, the files are gone permanently. Store the recovery key with the administrator password, in the safe.

    Keep the operating system and browser updated. Turn on automatic updates and let them run. And check what the machine is actually running. Microsoft ended support for Windows 10 on October 14, 2025, which means no more security fixes; consumers can enroll in Extended Security Updates, which deliver critical and important security fixes — nothing else, and no technical support — through October 12, 2027, and after that the machine is genuinely unsafe for handling donations. If your office computer is old enough that its operating system has been retired, that’s the budget conversation to have this year.

    Move the passwords out of the browser. Open the browser’s saved-password list, work through it, and move each one into a password manager — a separate encrypted app whose whole job is storing passwords, with a shared vault the office can use for the accounts several people genuinely need. Then delete them from the browser and turn off the offer to save.

    While you’re in there, sign out of the giving platform, the bank, and the church management system, and set them to require a sign-in each time. It’s ninety seconds of friction a day. It’s the ninety seconds that stands between a shared keyboard and your operating account.

    The objections are fair, and here’s the answer

    “Switching users is slow.” It is, a little. But nobody has to shut down — both systems let one person stay signed in while another switches over, and coming back takes a password. What makes it painless is doing the setup once: get each person signed in, let them set their own preferences, and the daily friction is a password.

    “The volunteers will grumble.” Some will. The framing that works is not security, it’s fairness: your account is yours, so nothing that happens on somebody else’s shift lands on you. People understand being protected from blame far faster than they understand threat models.

    “We’ll forget the passwords.” Yes, if you ask people to invent complicated ones. Don’t. Use a memorable passphrase of three or four unrelated words for the login itself, and let the password manager handle everything else. The administrator password in the safe turns a forgotten password into a five-minute fix.

    “It’s just the bulletin computer.” It’s the computer with the browser that’s signed in to your giving platform. It stopped being the bulletin computer some time ago.

    When the machine finally goes

    Eventually the old tower gets replaced, and someone offers to take it home, or it goes to a member starting a small business, or a recycler collects it.

    Deleting files does not remove them. Deleting marks the space as available for reuse; the contents sit there until something happens to overwrite them, and free recovery tools will pull them back. The FTC’s guidance for businesses is direct about this: use software designed to securely erase data, because ordinary delete commands aren’t sufficient. NIST’s federal guidance on media sanitization makes the same distinction — there is a difference between removing the pointer to data and removing the data.

    The practical version for a church office:

    If the machine was encrypted the whole time, you’re mostly there already. Destroying the encryption key makes the contents unreadable — one more reason to turn encryption on early rather than at the end.

    Use the built-in full reset. Windows offers a reset that removes everything, with an option to clean the drive rather than just delete files — choose that one, and expect hours. Modern Macs offer an erase-all-content-and-settings option that wipes the machine back to factory state. Sign out of the Microsoft or Apple account first, so your account isn’t tied to a machine you no longer control.

    If the drive held donor or member records and you can’t verify the wipe, destroy the drive. Remove it and have it physically destroyed. A drive is worth less than the trust of the people whose data was on it.

    Then clean up what the machine could reach. Change the passwords that lived in that browser, and sign out of active sessions on the giving platform and email. The computer leaving the building doesn’t sign it out of anything.

    What to do this week

    Sit down at the office computer for forty-five minutes with whoever knows it best. Open the browser’s saved-password list and read it out loud — the giving platform, the bank, the email account, whatever’s there. That list is the argument; you won’t need to make another one.

    Then do two things: turn on the automatic screen lock, and confirm full-disk encryption is on (BitLocker or device encryption on Windows, FileVault on Mac), writing the recovery key into the safe. Separate user accounts can be next week’s job, and they’ll go faster once the list has been seen.

    The office computer is one item on a longer list. MissionDefend’s free assessment asks plain-English questions about how your organization handles email, donations, member data, and accounts — including shared machines and saved passwords — and returns a baseline score with a ranked list of what to fix first.

    Join the launch list →

    No spam and no sales calls — just one email when it’s live.

    Related reading

    MissionDefend provides cybersecurity readiness assessments and educational guidance for churches and nonprofits. It is not a penetration test, a security audit, legal advice, or an incident response service.

    Sources: Microsoft, Device encryption in Windows; Microsoft, Windows 10 support has ended on October 14, 2025; Microsoft, Windows 10 Extended Security Updates; Apple, Protect data on your Mac with FileVault; Federal Trade Commission, Protecting Personal Information: A Guide for Business; National Institute of Standards and Technology, SP 800-88 Rev. 2, Guidelines for Media Sanitization.

  • Everyone Is an Admin: A Twenty-Minute Permissions Audit

    Everyone Is an Admin: A Twenty-Minute Permissions Audit

    A new small-group leader gets her login on a Wednesday. She’s a volunteer, she’s delightful, and she needs to see who’s in her group and email them about Thursday.

    She signs in, clicks around to find her group, and lands on a member profile. And there it is: a home address, a spouse’s phone number, the names and ages of two children, a note from three years ago about a hospital visit, and a giving history going back to 2019 with every amount.

    She didn’t go looking. It was simply on the screen, because when the church set the system up in a hurry, the fastest way to make sure nobody got stuck was to give everybody the top level of access.

    That’s how it happens in nearly every church. Not carelessness — expedience, under time pressure, years ago, by someone who has since moved on.

    This is not about trust. It’s about blast radius

    Say this out loud at your next staff meeting, because it disarms the whole conversation before it becomes awkward:

    We are not doing this because we don’t trust anyone. We’re doing it so that one stolen password doesn’t expose everything.

    Blast radius is a plain idea wearing a dramatic name. It means: when one account is compromised, how much does the attacker get? If every account is a full administrator, the answer is all of it — every address, every giving record, every note — no matter which of the twenty accounts they happened to catch.

    And accounts do get caught. Phishing — the fake email that leads to a convincing but counterfeit login page — was the most-reported crime type in the FBI’s 2025 figures, with 191,561 complaints. It doesn’t select for the senior pastor. It catches whoever clicks, and in a church that is statistically going to be a volunteer with an old password and no second step at login.

    The goal isn’t to make anyone prove they deserve access. It’s to make sure that the volunteer who runs the coffee rota, if phished on a Tuesday, costs you the coffee rota.

    The data that shouldn’t all travel together

    Your church management system holds the most sensitive information your organization has anywhere. Not the bank account — this. Four categories deserve to be separated from general access:

    Giving amounts. Who gave what, and when. In many congregations this is the single most closely-held fact about a person, and knowing it changes how people are treated. Very few staff need it, and the ones who do are usually the treasurer, the bookkeeper, and the senior pastor — and some churches deliberately exclude the pastor. Whatever your practice, it should be a decision, not an accident of software setup.

    Children’s records. Names, ages, guardians, pickup authorizations, allergies, sometimes photographs. This should be visible to children’s ministry leadership and to no one else. There are also legal dimensions here — background check records, retention obligations, and what you may keep about a minor — and those requirements vary by state. Ask a lawyer about your own; don’t take a blog’s word for it, including this one.

    Pastoral notes. Counselling records, hospital visits, crisis notes, prayer requests that were shared in confidence. If your system lets staff write private notes on a person’s profile, find out right now who can read them. In a great many churches the answer is “anyone with a login,” and the people writing those notes have no idea.

    Contact details and addresses. Lower-sensitivity, but not zero — for someone in a domestic violence situation, an address in a widely-accessible directory is a genuine safety issue. Some systems support a confidential or restricted flag on individual records. Find out whether yours does.

    Systems differ in how finely they slice this, but the principle doesn’t: these four should be four separate decisions, not one.

    The question to ask about each person

    Not do we trust them? Everyone will say yes and the meeting will end.

    Not might they ever need this? That question always answers yes, and it’s how you got here.

    The question is: what does this person need to do their job this month?

    The month framing does the work. It converts a hypothetical into a concrete recollection. The office administrator needs to add new households and update phone numbers — this month. The children’s director needs check-in and guardian records — this month. The small-group leader needs the roster and email for her group — this month. The treasurer needs contribution records — this month.

    Nobody needs all four categories to do anything this month. When somebody does need something extra — pulling year-end statements, running a report for the board — grant it, do the task, and take it back. Temporary access is normal in every other part of church life. You give someone a key to the building for a season and then you ask for it back, and nobody takes offence.

    The twenty-minute routine

    Do this once now, then twice a year. Set a timer; the constraint is what makes it repeatable.

    Export the user list. Most platforms will let you export or print the list of people who have logins and what level each one holds; if yours won’t, a screenshot or a typed-up copy does the job. Get it onto one page where you can see all of it at once. This step alone is usually the shock — churches routinely find far more active accounts than anyone in the room expected.

    Group people by what they actually do. Not by their title. Sort the list into rough buckets: office and administration, finance, children and youth, pastoral, group leaders, and a bucket for anyone you can’t place. Four or five roles covers almost every church.

    Find the accounts nobody recognizes. There will be some. The consultant who did your setup. An email address at a domain the church no longer uses. A name three people vaguely remember. A generic login called “office” or “admin” whose password is known to an unknown number of people. Deal with these first — they’re the highest-risk items on the page and the easiest to close, because nobody will miss them.

    Downgrade before you delete. This is the step that keeps the whole exercise from going wrong. Deleting a user in a church database can orphan the records they created, break reports, or remove notes someone else relies on. So drop people to the lowest level that matches their bucket, and leave the account in place. Watch for a month. If someone genuinely can’t do their job, you’ll hear about it in a day and you can restore it in thirty seconds. Then delete what’s still unused. Downgrading is reversible and quiet; deleting is neither.

    Write down the roles and set the next review. One paragraph in a shared document: here are our five roles, here’s what each can see, here’s who decides. Then put a recurring appointment in the calendar — twice a year is plenty, and pairing it with something you already do, like the annual meeting or the start of the program year, means it actually happens.

    The doors nobody audits

    Two categories sit outside the user list entirely, which is exactly why they get missed.

    Integrations and API keys. An API key is a long string of characters that lets one piece of software log into another without a human being present. Your giving platform talks to your church database. Your website’s event form pushes registrations in. A texting service reads your contact list. A volunteer’s clever spreadsheet syncs attendance. Every one of those connections holds standing access, often at a high level, and it does not appear in the staff list you just reviewed.

    Find the integrations or connected-apps section of your system and read it with the same question: do we still use this, and does it still need that much? Pay particular attention to anything created by someone who has left, and to keys generated by a volunteer for a project that finished. Those keys don’t expire because a person moved away. Revoke and regenerate anything you can’t account for.

    Volunteers on personal phones. Most of your group leaders and children’s workers access the system on a phone that is also used by their spouse, their teenager, and occasionally the family iPad. That phone may have no lock code. It stays signed in indefinitely. If it’s lost at a football game, a member of your congregation’s home address is in a stranger’s hand.

    You cannot manage those devices, and you shouldn’t try. What you can do is ask three things of anyone with a login: use a lock screen, turn on the extra step at sign-in if your platform offers it, and tell the office immediately if the phone is lost so the account can be signed out. Then find out now — not on the day it matters — whether your system can sign a user out of every device at once or force a password reset, and where that control lives.

    The same shape, whatever platform you’re on

    Churches run on Planning Center, Breeze, Tithely, Church Community Builder (now branded Pushpay ChMS), Realm, and a dozen others. Each names things differently, and the names change; the underlying concepts don’t, which is why this article describes them rather than giving you a menu path that would be wrong by next spring.

    Look for: a list of users and their permission level; named roles or permission groups you can define once and reuse; separate toggles for financial and giving data; separate handling for children’s and check-in records; a restriction on who can read private or pastoral notes; a way to mark an individual record confidential; and a connected-apps or API section. Not every platform has all of these. If yours is missing one — particularly the ability to hide giving amounts from general users — that’s a legitimate question to put to their support team, and a legitimate factor when you next review the contract.

    What to do this week

    Export the user list. Just that, first — it takes five minutes and it will tell you more about your actual risk than an hour of reading.

    Then spend fifteen minutes on the two highest-value items: close the accounts nobody recognizes, and check who can see giving amounts. If the answer to that second one is “everybody,” fix it today. It’s usually a single setting, and it’s the one your congregation would most want fixed.

    Permissions are one of the fastest wins available to most churches. MissionDefend’s free assessment asks straightforward questions about how your organization handles member data, donations, email and accounts — no jargon, no product pitch — and returns a baseline score with a ranked list of what to address first.

    Join the launch list →

    No spam and no sales calls — just one email when it’s live.

    Related reading

    MissionDefend provides cybersecurity readiness assessments and educational guidance for churches and nonprofits. It is not a penetration test, a security audit, legal advice, or an incident response service.

    Sources: FBI Internet Crime Complaint Center, 2025 Internet Crime Report.

  • Protecting the Livestream, the Funeral, and the Small Group Call

    Protecting the Livestream, the Funeral, and the Small Group Call

    The funeral is on a Saturday morning. Forty people in the sanctuary and sixty more watching from Ohio, Arizona, and a hospital room in Nashville, because that’s who the livestream is for — the family who couldn’t travel.

    Eight minutes in, during the eulogy, someone joins the call and shares their screen. What appears is pornographic. Then a second person joins, and there’s shouting over the audio and slurs in the chat, and the volunteer at the laptop at the back is clicking frantically through a settings menu he has never opened while a woman in the front row watches her mother’s funeral come apart.

    It lasts ninety seconds. People will remember it for thirty years.

    This is the article about making sure that doesn’t happen at your church, written so the person running the laptop can follow it. But start with the right frame: this is a pastoral emergency that happens to have a technical cause. The technical part is genuinely easy. The part where you sit with the family afterward is not, and it’s the part most guidance leaves out.

    The root cause is the permanent public room

    Nearly every incident traces back to one habit: a meeting room that is always the same address, always open, and posted where anyone can find it.

    It’s a reasonable habit. You want people to join without friction, and grandparents shouldn’t need a new link every week. So the link goes on the website, in the bulletin PDF, on the Facebook page, and into an email list that gets forwarded — and stays there, unchanged, for years.

    Which means it can be found. There are people who do nothing but collect these links from public pages and forwarded emails and pass them around, in order to disrupt whatever’s on the other end. Schools, council meetings, recovery groups, and churches are the usual targets, because all of them publish.

    The FBI has warned about exactly this since 2020, when it documented unidentified people disrupting video meetings with pornographic imagery, hate images, and threats. Its first two recommendations were plain: don’t make meetings public, and don’t post the link on unrestricted public social media.

    That’s the fix. The rest of this is how to do it without making it hard for an eighty-year-old to attend Bible study.

    You have three tools for controlling entry, and you don’t need all three at once.

    A waiting room. Everyone who clicks the link lands in a holding area and a host lets them through. This is the single most valuable setting in this article, and it’s on by default in most platforms now. For a group of twenty, admitting people takes fifteen seconds and you recognize every name.

    A passcode, required to join and separate from the link. Fine for a recurring small group; less useful for anything published widely, since it travels with the link.

    Registration. Attendees give a name and email in advance and receive their own personal join link. This is the right choice for a funeral. It takes the family two minutes to share a registration page with relatives, and it makes the guest list a known quantity on the hardest morning of their lives.

    Alongside that, three habits:

    Use a fresh link for anything sensitive — a funeral, a board meeting, a care group. Never the standing Sunday room. A one-off link is a one-off exposure.

    Don’t publish the link where it can be harvested. Put a button on your website behind a click-through or a short form, rather than pasting the raw meeting address into a public page, a printable bulletin, or a Facebook post. For a congregation, email and text is enough.

    Separate broadcasting from meeting. This is the biggest structural improvement most churches can make. A Sunday service doesn’t need to be a meeting — nobody in the congregation needs a microphone. Stream it to YouTube or Facebook instead, where viewers can only watch, and reserve the interactive platform for small groups where you actually want people talking. Half this problem disappears the moment the service stops being a room anyone can walk into.

    Take away the tools before anyone needs them

    Every disruption uses a capability the meeting handed out by default. Turn them off ahead of time, in your account settings — not in each individual meeting, where they’ll be forgotten. Menus change every few months, so here they’re described by what they do:

    Only the host can share their screen. The one that matters most. Screen sharing is how an image gets onto everyone’s display at once, and no participant needs it during a service. In a small group the leader can grant it for a moment when it’s needed.

    Turn off annotation — the tool that lets participants draw on whatever is being shared. It exists for classrooms. In these incidents it’s used to draw obscenities over a hymn slide.

    Turn off participant renaming. Renaming is how someone joins as “Pastor Dan,” or as something vile that then sits in everyone’s participant list.

    Then four smaller ones: mute participants on entry; in large gatherings, prevent them unmuting themselves; turn off private chat and file transfer; and don’t allow people to join before the host, because an unattended room is an empty stage.

    Name a second person whose only job is to watch

    This is the recommendation most likely to be skipped, and the one that actually saves a funeral. The person running the camera and audio cannot also moderate — their hands and attention are already committed, and in an incident the seconds spent hunting for the right menu are the seconds that do the damage.

    So name a second person, a volunteer sitting anywhere, even at home, signed in as a co-host — a role you assign that grants the ability to mute, remove, and lock. Their whole job is to watch the participant list and the chat.

    Give them three things: co-host permission, granted the moment the meeting opens rather than in the middle of an incident — Zoom, for one, only lets you promote a co-host once the meeting is running, so make it the first thing you do; a printed card with the four actions below; and explicit authority. Say that last one out loud: you don’t need to ask anyone. Remove first, explain later. Volunteers hesitate because they’re afraid of removing the wrong person. Removing a confused church member by mistake costs you an apology. Hesitating costs a family a funeral.

    Then practice once, for five minutes, in an empty meeting: have someone join and have the moderator remove them. Muscle memory is the point.

    The thirty-second response

    Print this and tape it to the sound desk.

    1. Mute everyone. There is a mute all control, and it’s the fastest way to stop audio. Do it first — sound reaches more people than an image does.

    2. Stop the screen share. A host or co-host revoking participants’ screen-share permission in the security controls ends a share in progress and clears the image from every screen at once. On Zoom, a single suspend participant activities control does that, mutes everyone, and locks the meeting together.

    3. Remove and report. Removing a participant takes two clicks from the participant list, and most platforms put a report option alongside it that ejects them and sends the account to the platform’s trust and safety team. Use report, not just remove — it gives the platform a record.

    4. Lock the meeting. Once the disruptors are out, locking keeps anyone new from entering. Latecomers are shut out for a few minutes; an acceptable trade.

    And for a stream, cut to a holding card. Keep a static image one keystroke away before every service — the church logo, or a slide reading We’re experiencing a technical difficulty and will return shortly. Switching to it is a calm, defensible act that buys you sixty seconds. Watching an operator scramble on camera is not.

    When it’s over, end the meeting entirely rather than continuing in it.

    Comments and chat on YouTube and Facebook

    Streaming instead of meeting solves the intrusion problem but introduces a smaller one: the comment stream running down the side of your service. Those controls are separate.

    On YouTube, live chat moderation lives in your channel’s community settings. Use three things: a blocked-words list, which blocks any live chat message containing terms you specify — putting the obvious slurs in it is a fifteen-minute job that runs forever; the filter that holds potentially inappropriate messages for review; and named moderators, channel roles letting trusted volunteers remove messages and hide users during a stream without having your password. On Facebook, page moderation works the same way: a profanity filter with adjustable strength, a custom blocked-words list, and a way to give trusted volunteers moderation access so they can hide comments and ban accounts without your password.

    On both, “hide” beats “delete” — a hidden comment stays visible to whoever wrote it, so they don’t immediately notice and repost.

    And the simplest control of all: turn live chat off for services where it adds nothing. Turn it on for the Wednesday study, where conversation is the point, and off on Sunday.

    Afterward: the part that isn’t technical

    If it happens, the technology stops mattering within two minutes and the pastoral work begins.

    Name it out loud, immediately. Don’t push through as if nothing occurred. When you come back on, say plainly: Someone deliberately disrupted our service. That was an attack on us, it was nobody’s fault here, and it’s over now. Silence lets people assume it was somehow the family’s doing, or the church’s negligence.

    Go to the family that day, in person. Not by email. Say clearly that this was done to them by strangers who target funerals precisely because they are tender, that it says nothing about their mother or their church, and that you are sorry. Ask what they want done about the recording — usually the answer is delete it, and be ready to say yes immediately. Take it down in the meantime; you can always restore it, and you can’t unshow it.

    Tell the volunteer it wasn’t their fault, and mean it. The person at the laptop will carry this longer than anyone but the family, and will consider quitting. They weren’t trained, weren’t equipped, and the settings were not their decision.

    Say something to the congregation in the next communication: what happened, what you’ve changed, who to talk to if they’re shaken. Recovering trust here depends far more on visible correction than on explanation.

    And report it, because this is not merely rude behavior. The Department of Justice has stated plainly that hijacking a teleconference can be charged as a state or federal crime, listing possible charges including disrupting a public meeting, computer intrusion, using a computer to commit a crime, hate crimes, fraud, and transmitting threatening communications, with penalties including fines and imprisonment.

    Report it three places: the platform, using the in-meeting report function while it’s happening if you can, since that preserves account data on their side; the FBI at ic3.gov, with the date, time, and display names used; and local police, particularly if there were threats, if the content involved children, or if the disruption was religiously or racially targeted. Ask whether it should be reported as a hate crime — in many places, targeting a religious service changes the classification.

    Before deleting anything public, save what you have offline: screenshots of the participant list, the chat log, and the recording.

    What to do this week

    Open your video platform’s account settings — not one meeting’s, the account’s — and set four things: waiting room on, screen sharing host-only, annotation off, renaming off. Ten minutes, once, for every meeting you will ever hold.

    Then name your moderator. Text one reliable volunteer, ask them to be co-host on Sunday, and send them the four-step card: mute all, stop the share, remove and report, lock the meeting. Tell them they have authority to act without asking.

    That’s twenty minutes, and it’s the difference between ninety seconds and thirty years.

    Wondering what else is sitting unlocked? MissionDefend’s free assessment asks plain questions about your accounts, your member data, your email, and your online giving, then returns a baseline score and a ranked list of what to close first.

    Join the launch list →

    No spam and no sales calls — just one email when it’s live.

    Related reading

    MissionDefend provides cybersecurity readiness assessments and educational guidance for churches and nonprofits. It is not a penetration test, a security audit, legal advice, or an incident response service.

    Sources: Federal Bureau of Investigation, Boston Division, FBI Warns of Teleconferencing and Online Classroom Hijacking During COVID-19 Pandemic; U.S. Department of Justice, Eastern District of Michigan, Federal, State, and Local Law Enforcement Warn Against Teleconferencing Hacking During Coronavirus Pandemic.

  • Tailgating and the Unlocked Door: Social Engineering in Person

    Tailgating and the Unlocked Door: Social Engineering in Person

    On Tuesday morning the side door by the kitchen is propped open with a folding chair, because the food pantry delivery comes on Tuesdays and the volunteers got tired of walking around to let the driver in.

    At 9:40, a man in a polo shirt with a lanyard and a toolbox walks through it. He nods at the volunteer sorting cans — she nods back — and heads down the hall toward the office with the unhurried walk of a man who has been here before. He has never been here. In the next eleven minutes he will be alone with the office computer, the top drawer where the spare key lives, and the filing cabinet with last year’s giving statements.

    Everything this series has covered so far arrives through a screen or a phone. This one walks in. Tailgating is the physical version of social engineering: following someone through a door they unlocked, or being let in because you look like you belong. Security people also call the polite variant piggybacking — where the victim actually holds the door — but the distinction doesn’t matter much in practice. The attack is the same: skip the lock by borrowing someone else’s trust.

    Why a church is the easiest building in town

    It’s worth being honest about this: a church is designed to be walked into. That is the point of the building. The signage says welcome, the culture says welcome, and on any given day the people inside include members, visitors, contractors, delivery drivers, twelve-step groups, tutoring programs, and someone’s cousin picking up folding tables. Nobody can say who “belongs,” because the honest answer is almost everyone.

    CISA — the federal Cybersecurity and Infrastructure Security Agency, which runs a program specifically for houses of worship — frames the problem exactly this way: security planning for congregations has to work with “a congregation’s desire for openness and access,” not against it. The goal is not a church that interrogates strangers. The goal is a church where openness is a decision, not an accident.

    And notice what the intruder in the polo shirt was actually after. Not the sound equipment. The office — because in 2026 the valuable thing in your building is data and access: the computer that’s still logged in, the passwords in the drawer, the donor records, the blank checks, the network jack behind the desk. Physical entry is how an attacker with no technical skills gets everything a hacker wants.

    The four moves, so your team can name them

    The borrowed opening. The propped door, the loading dock during an event, the stream of people arriving for a funeral. No deception needed — just timing. Big, emotional gatherings are ideal cover; nobody checks faces at a funeral.

    The full hands. Boxes, coffee cycles, a ladder — anything that makes a decent person hold the door. The costume does the arguing: florist during a wedding week, HVAC in summer, “the piano tuner” any time.

    The confident walk. No interaction at all. Enter during office hours, move like you have an appointment, know that the person who might ask questions will assume someone else already did. This is pretexting performed with posture instead of a phone call.

    The advance call. The strongest version pairs both: a phone call Monday — “we’ll have a tech out Thursday for the fire panel inspection” — so that Thursday’s visitor is expected. Expected strangers get escorted to the electrical room and left alone.

    What to do this week

    Retire the propped door; give the regulars a better path. A door held open by a chair is an unlocked building with extra steps. Solve the reason it was propped: a doorbell at the delivery entrance that actually rings where volunteers are, a posted delivery window when someone staffs that door, or a keypad code for the food-pantry team that changes each season. People prop doors when the secure path is annoying. Make the secure path the easy one.

    Draw the one line that matters. Most of the building can stay gloriously open. Pick the two or three spaces that can’t — the office, wherever records and money live, the room with the network equipment — and treat those doors as the perimeter: locked when unoccupied, every time, even for ten minutes. “Locked office, open building” preserves the welcome and removes the prize. Pair it with the screen-lock habit: an office computer left logged in behind an unlocked door is the whole breach, pre-assembled.

    Replace suspicion with hospitality — literally. Train everyone on one move: greet the stranger. “Hi! Can I help you find something?” Warm, natural, entirely on-brand for a church — and devastating to a tailgater, whose whole method is moving unquestioned. A legitimate visitor gets directions. An intruder gets a decision point. Add the escort norm for anyone doing work in a restricted area: contractors are expected visitors with company, not wanderers.

    Verify the advance call like any other pretext. “We’re sending a tech Thursday” gets the same treatment as every unsolicited contact in this series: call the company back on the number from your contract, not the number that called you. And keep a plain sign-in sheet for non-Sunday visitors and workers — not as bureaucracy, but so that “who was in the building Tuesday?” has an answer.

    One more thing worth knowing exists: CISA offers houses of worship a free self-assessment guide and access to regional Protective Security Advisors who will walk your building with you, and FEMA runs a Nonprofit Security Grant Program that has funded exactly these kinds of improvements. You do not have to invent this from scratch.

    The doors of the church should be open. That line is theology, and nothing here argues with it. But open should describe the sanctuary and the welcome — not the filing cabinet, the finance computer, and the drawer with the spare keys. Lock the three doors that matter, greet everyone else, and you’ve kept both promises.

    The MissionDefend assessment covers the physical side of data protection — where records live, who can reach them, what’s locked — alongside the digital. Join the launch list for first access when it opens.

    Sources: Cybersecurity and Infrastructure Security Agency, Protecting Houses of Worship; FEMA, Nonprofit Security Grant Program; Federal Trade Commission, FTC Announces Impersonation Rule Goes into Effect Today (April 1, 2024).

  • Summer Volunteers, Permanent Access

    Summer Volunteers, Permanent Access

    It’s the second Monday in June and the hallway outside the fellowship hall has been turned into a check-in station. There’s a folding table, a laminated sign, a bin of name tags, and a tablet on a stand.

    Behind the table is a seventeen-year-old who is wonderful with children and has never used the check-in system before. Someone shows her how it works in about ninety seconds. She taps in as VBS, because that’s the login on the sticky note attached to the tablet stand, and for the next five days she checks in a hundred and forty children — with their parents’ phone numbers, their allergies, their medications, and the notes about which adult is and isn’t allowed to collect them.

    In August she leaves for college.

    In September, nobody does anything. The VBS login still works. It will still work next June, and the June after that, and the sticky note is still on the stand.

    This isn’t a story about a bad volunteer. She was excellent, and the church was lucky to have her. It’s a story about a pattern that almost every church repeats every summer without noticing: the people with the least training and the shortest tenure are handed access to the most sensitive information the organization holds, and nobody ever takes it back.

    The summer problem, stated plainly

    Vacation Bible School, day camp, sports camps, mission trips, summer interns, the youth trip. For six to ten weeks, a church’s headcount of people-with-access can double.

    They need real access — this isn’t a case where you can hand out nothing. The check-in table needs the check-in system. The registration volunteer needs the registration data. The intern posting daily photos needs the social accounts. The trip coordinator sometimes needs a card to buy fuel and groceries in another state.

    And three things are true of this group at the same time:

    Highest turnover. Many of them serve for one week and are never in the building again in that capacity. Some are students who leave in a fixed month.

    Lowest training. They are recruited late, briefed quickly, and often start on the first morning. Nobody schedules an orientation for a person doing one week of a volunteer job.

    Most sensitive data. Children’s names, ages, photographs, allergies, medical notes, emergency contacts, home addresses, and — in some systems — custody restrictions. There is nothing else in a church’s records more sensitive than that.

    Any two of those would be worth attention. All three, every summer, on a shared login, is the thing to fix — and it is genuinely fixable. This is not a technology problem; it’s a pattern that someone has to own.

    Named accounts, with an end date decided first

    Start here; everything else depends on it.

    A shared login costs you the same four things it costs on a shared office computer: nobody can tell who did what, one leaked password exposes everything, the password never changes because changing it means telling forty people, and every volunteer who ever served still has it.

    There’s a particular version of that for children’s ministry. If a parent raises a concern about how a check-out was handled, or a record was changed, or a photo was posted, a shared login means nobody can establish what happened. That protects nobody — least of all the volunteers, who all become equally unaccountable and therefore equally unclearable.

    Give each summer volunteer their own account, under their own name. Most church management and check-in systems allow unlimited or generous numbers of users, and the ones that charge per user often have a volunteer or limited role at a lower cost or none. Ask your vendor before assuming every extra person is a paid seat.

    If your system genuinely cannot do named volunteer accounts, write that down as a known limitation and raise it at renewal.

    The second half of the pattern is almost embarrassingly simple:

    Nobody gets access without a written end date, and the end date is written down before the access is granted.

    Not “we’ll remove it when they’re done.” That sentence has never once resulted in access being removed. A date. On a list. In the calendar.

    A one-page grid is all you need — a spreadsheet, a shared doc, a printed sheet in a binder. Five columns:

    Name · What they can get into · Start date · End date · Removed (initials and date)

    That’s the whole system. It converts a vague intention into a specific task with a name attached, and it gives you something to hand to an insurer or a board member who asks a fair question.

    Add one calendar entry — mid-September, titled Remove summer access, assigned to a specific person — and this problem is structurally solved for as long as somebody keeps doing it.

    The minimum permissions for the job

    The FTC’s guidance for businesses puts it as the principle of least privilege: each person should have access only to what they need to do their particular job. In a church that translates into a few concrete decisions.

    The check-in volunteer needs to check children in and out. She does not need to edit family records, view giving history, export the directory, or see the full membership database. Most check-in systems have a limited role for exactly this; find it and use it.

    The registration volunteer needs this summer’s registrations. Not the historical file, not the donor records.

    The intern posting photos needs to post. Most social platforms let you grant a person permission to publish without giving them the ability to change the password, remove other administrators, or delete the account. Use that level — and never hand over the account password itself.

    Almost nobody needs a payment card. If a trip leader genuinely does, a dedicated card with a low limit that gets canceled at the end of the trip is far better than a card tied to the operating account. Ask your bank about a virtual or single-use card.

    Two more, a minute each. Turn on multi-factor authentication — the extra code or tap after a password — for any volunteer account that can reach children’s data or money. Microsoft’s research finds it blocks more than 99.2% of account compromise attacks, and it is just as free for a volunteer as for the pastor. And remove the shared passwords from sticky notes on tablet stands; a printed card kept behind the table, changed after the season, is already an improvement.

    Fifteen minutes of orientation, and only three things in it

    You will not get a training session. You’ll get the first five minutes of the first morning, standing at a folding table. So decide in advance what the three things are.

    One: this data is not yours to share. Names, allergies, custody notes, and phone numbers stay in the system and in this building. Not screenshotted, not texted to a co-leader, not typed into a personal spreadsheet, not posted anywhere. “If you find yourself about to photograph the screen, stop and ask me instead.”

    Two: check-out is a security function, not a formality. The person collecting a child is matched to the record every time — when you know them, when there’s a line, when they’re annoyed about it. Custody restrictions are the reason the system exists. A volunteer told this once will hold the line; a volunteer who hasn’t will assume the tags are bureaucracy.

    Three: if anything seems wrong, tell this person. Point at a specific human being. An email that looks odd, a parent who seems agitated, a stranger in the hallway, a screen that logged you into somebody else’s account. Nobody is ever in trouble for asking.

    Then one line about photographs, because summer is when the photo problem happens: know which children have a photo restriction on file, and know that a group of happy kids is not a reason to skip checking. Photo consent deserves its own conversation with your leadership — who may photograph, what may be published where, and how a family opts out — and the summer programs are exactly when a vague policy gets tested.

    The phone in their pocket

    Here’s the modern wrinkle. Many check-in and ministry apps run on personal phones, and a volunteer installing the app on her own device is often the fastest way to get the table staffed.

    That’s a reasonable trade, but be clear-eyed: church data is now on a phone the church doesn’t control, that gets handed to a younger sibling, that may have no screen lock, and that will be traded in eventually.

    Three things make it acceptable:

    Say plainly that the app must be signed out of and deleted when the season ends — and put that on the same one-page grid, with a tick box, so it’s a task rather than a hope.

    Ask for a screen lock and current updates on any phone used for ministry data. That’s not intrusive; it’s the same thing the volunteer’s bank asks of them.

    Prefer a church-owned tablet where you can. One inexpensive tablet in a stand that never leaves the building removes almost all of this, and it’s a strong candidate if you’re buying one device this year.

    And when a volunteer’s access ends, remember that removing their account in the system is what actually matters — an app left on a phone with no working login is just an icon.

    September, and how to say it without awkwardness

    Put the calendar entry in now, whatever month you’re reading this in. Mid-September, one person, thirty minutes:

    Work down the grid and remove every access whose end date has passed. Initial the last column.

    Check each system’s user list separately — check-in, church management, email, the giving platform, the shared drive, the social accounts, the photo library. People collect access in places the grid doesn’t know about.

    Look specifically at the social accounts. They’re the most often forgotten, and the most public when it goes wrong.

    Change any password that was shared during the season, and any that was on a card at a table.

    Then tell the volunteers you did it, in the thank-you note — which brings us to the one thing that actually stops churches from doing any of this.

    It isn’t ignorance. It’s that removing someone’s access feels like an accusation, and in a community built on trust, accusing a faithful volunteer of anything is unthinkable.

    So take the implication away by saying it before it can be inferred, at the start rather than the end:

    “Your access runs through the last week of August. That’s how we do it for everyone, including the pastor’s family. It’s not about trust — it’s that we keep the children’s information locked down to whoever is actually serving right now.”

    Nobody has ever been offended by that. What people are offended by is being singled out, and a policy applied to everybody singles out nobody.

    A church that can say we give named accounts, limited to the role, for a fixed period, and we remove them in September is a church that can answer questions from parents, insurers, and its own board with something better than reassurance. A two-week volunteer with a two-week account is not distrust. It’s ordinary practice, and it protects the volunteer as much as the child.

    What to do this week

    Open the user list for whichever system holds your children’s check-in data and read it top to bottom. Look for names you don’t recognize, accounts called things like VBS or Camp or Front Desk, and people who left. That takes fifteen minutes, and it is usually a surprising fifteen minutes.

    Then make the grid — name, access, start, end, removed — even if the only thing on it today is next summer. And put one entry in the church calendar for mid-September with somebody’s name on it.

    Seasonal access is one strand of a larger question about who can reach what. MissionDefend’s free assessment asks plain-English questions about how your organization handles email, donations, member data, and accounts — including who has access to what, and who removes it — then returns a baseline score with a ranked list of what to fix first.

    Join the launch list →

    No spam and no sales calls — just one email when it’s live.

    Related reading

    MissionDefend provides cybersecurity readiness assessments and educational guidance for churches and nonprofits. It is not a penetration test, a security audit, legal advice, or an incident response service.

    Sources: Federal Trade Commission, Protecting Personal Information: A Guide for Business; Microsoft, mandatory multifactor authentication guidance.