Information Technology

Technical Resources for Parishes

AOS Guardian

What is AOS Guardian?

AOS Guardian is a cybersecurity design approach and framework established by the Archdiocese of Seattle to guide how parishes, schools, and ministries protect their digital environments. Rather than being limited to a single product or toolset, AOS Guardian represents a standardized, layered approach to security that can be implemented through approved platforms or equivalent solutions.

As cybersecurity threats have become more frequent and sophisticated, organizations are increasingly vulnerable to risks such as phishing, credential theft, impersonation, and data compromise. These threats target both technology systems and the people who use them.

AOS Guardian addresses this challenge by promoting a “defense in depth” strategy—combining multiple layers of protection, including secure access controls, endpoint protection, monitoring, backup, and user education. This approach ensures that if one layer is bypassed, additional safeguards remain in place to reduce the likelihood of a successful attack.

Ultimately, AOS Guardian is about establishing a unified standard for cybersecurity—one that protects sensitive information, reduces operational risk, and supports the responsible stewardship of digital resources throughout the Archdiocese.

AOS Guardian - Cybersecurity Threats Escalate for Catholic Parishes and Schools in Western Washington

Cybersecurity Threats Escalate for Catholic Parishes and Schools in Western Washington

July 2025 | Seattle, WA — Catholic parishes across Western Washington are facing a growing wave of cybersecurity threats, with phishing and token theft attacks emerging as particularly dangerous vectors. These incidents are not only compromising sensitive data but also threatening the financial and operational stability of faith communities.

A New Era of Cyber Threats

Recent cybersecurity incident reports reveal a sharp increase in business email compromise (BEC) and token theft attacks, even among organizations that have implemented multi-factor authentication (MFA). In many cases, attackers are bypassing MFA by stealing session tokens through sophisticated phishing campaigns.

These tokens, once stolen, allow attackers to impersonate legitimate users without needing passwords or MFA codes. This method has proven especially effective in environments where legacy systems or insufficient cybersecurity training leave gaps in defense.

Why Faith-Based Institutions Are Vulnerable

Parishes and schools often operate with limited IT resources and outdated infrastructure. Common vulnerabilities include:

· Unsecured email systems that are easily spoofed.

· Lack of cybersecurity training among staff and volunteers.

· Use of legacy software that does not support modern security protocols.

· Inadequate backup and recovery plans in the event of a breach.

Catholic Schools: A Growing Target

Catholic schools in the region are also increasingly vulnerable. According to the 2025 CIS MIS-ISAC K-12 Cybersecurity Report, attacks on the education sector rose by 224% in 2024. These attacks are not only more frequent but also more sophisticated, often using AI-generated phishing emails, cloned portals, and fake financial aid forms to deceive staff and students.

Cybersecurity leaders in the region emphasize that schools are attractive targets due to the sensitive data they hold—student records, financial information, and login credentials—and the disruption a successful attack can cause canceled classes and lost learning time.

Phishing: The Gateway to Exploitation

Phishing remains the most common entry point for attackers. These scams often impersonate trusted figures—such as pastors or diocesan officials—and request urgent financial transactions or login credentials. In some cases, attackers have successfully redirected parish donations or payroll funds to fraudulent accounts.

The emotional and spiritual trust that parishioners place in their church leaders makes these communities especially susceptible to social engineering tactics. As one cybersecurity expert noted, “These attacks rely on emotion—urgency, fear, or trust—to bypass rational scrutiny.”

Phishing is a type of cyberattack where attackers try to trick people into giving away sensitive information—like passwords, credit card numbers, or access tokens—by pretending to be someone they trust.

🔍 How Phishing Works

Phishing usually happens through:

Emails that look like they’re from a trusted source (e.g., a bank, employer, or even a parish leader).
Fake websites that mimic real ones to steal login credentials.
Text messages or phone calls asking for urgent action.

🎯 Common Tactics

Urgency or fear: “Your account will be locked unless you act now!”
Impersonation: “This is Father John. Can you send me the gift card codes?”
Links to fake login pages: These pages look real but are designed to steal your username and password.

🛡️ How to Protect Yourself

Don’t click suspicious links—hover over them to see where they really go.
Verify requests—especially those involving money or sensitive info.
Use multi-factor authentication (MFA)—and be cautious even with MFA, as attackers can steal session tokens.
Report phishing attempts to your IT team or email provider.

Local Impact and Response

While specific incidents in Western Washington have not all been made public, cybersecurity firms and diocesan IT departments confirm that several parishes have experienced attempted or successful breaches in the past year. The Archdiocese of Seattle has reportedly increased its investment in cybersecurity awareness training and is encouraging parishes to adopt stronger email authentication protocols and endpoint protection tools.

Recent Exploits Involving Paycom and Token Theft

In early 2025, several archdiocese schools using Paycom reported incidents where attackers exploited session token theft to gain unauthorized access to employee accounts. These attacks typically began with phishing emails that tricked users into logging into fake Paycom portals. Once credentials and session tokens were captured, attackers bypassed multi-factor authentication and accessed employee dashboards. In many cases, they redirected direct deposit information, rerouting paychecks to fraudulent bank accounts before the breach was detected. The incidents highlight the growing threat of token-based attacks, even in systems with MFA, and underscore the need for phishing-resistant authentication and vigilant monitoring of payroll systems.

Recommendations for Parishes and School

A Call for Vigilance

As cybercriminals become more sophisticated, Catholic parishes and schools must adapt quickly to protect their communities. The spiritual and educational missions of the Church depend not only on faith but also on the security of the systems that support them.

Additional Technical Information:

🔐 What Is a Session Token?

A session token is a small piece of data that a website or application uses to identify and authenticate a user after they log in. Instead of asking for your username and password every time you click a link or load a new page, the system gives you a token—like a temporary ID badge—that proves you're already logged in.

🧩 How It Works:

You log in with your credentials.
The server verifies your identity and issues a session token.
This token is stored in your browser (usually as a cookie or in local storage).
Every time you interact with the site, your browser sends the token to prove who you are.

⚠️ Why It’s a Security Risk:

If an attacker steals your session token—for example, through a phishing attack or malicious browser extension—they can impersonate you without needing your password or MFA code. This is how many recent attacks, including those involving Paycom, have bypassed even strong security measures.

How To - Implement Phishing-Resistant MFA (e.g., Hardware Security Keys)

What It Is: Unlike traditional MFA (like SMS codes or app-based prompts), phishing-resistant MFA uses physical devices—such as USB or NFC security keys—that must be present to log in.

Why It’s Safer: Hardware keys cannot be tricked by fake login pages. They only work with legitimate websites, making them highly resistant to phishing and token theft.

How It Works: When logging in, the user plugs in the key or taps it on their device. It verifies the website’s identity before allowing access.

Who Should Use It: Ideal for staff with access to sensitive systems, such as finance, student records, or email administration.

Examples of Hardware Keys: YubiKey, Google Titan, SoloKey.

Bonus: Many keys support multiple accounts and services, including Google Workspace, Microsoft 365, and password managers.

How To - Educate Staff and Volunteers on Recognizing Phishing and Social Engineering

Phishing Awareness:

Teach staff to inspect email addresses carefully—look for subtle misspellings or unusual domains.
Encourage them to hover over links before clicking to see where they really lead.
Remind them: legitimate organizations never ask for passwords or sensitive info via email.

Social Engineering Tactics:

Attackers may impersonate trusted figures (e.g., pastors, principals, IT staff) to create a false sense of urgency.

Common red flags: requests for gift cards, wire transfers, or login credentials—especially if the tone feels “off.”

Training Tips:

Use realistic phishing simulations to test and reinforce learning.
Offer short, regular training sessions—not just once a year.
Encourage a “report, don’t ignore” culture: better to report a suspicious message than to assume it’s safe.
Empower, Don’t Shame:
Make it safe for staff and volunteers to ask questions or admit mistakes.
Celebrate successful phishing catches to reinforce good habits.

How To - Audit and Update Legacy Systems to Support Modern Security Standards

Why It Matters:

Legacy systems often lack support for modern encryption, multi-factor authentication, and security patches.
These outdated systems are prime targets for attackers looking for easy entry points.

Audit Checklist:

Identify all systems and software in use—especially those handling email, finances, student records, or donor databases.
Check for end-of-life software (e.g., Windows 7, old versions of Office or email servers).
Review user access levels—remove or limit access for inactive or unnecessary accounts.

Update Priorities:

Upgrade to cloud-based platforms with built-in security (e.g., Microsoft 365, Google Workspace for Education).
Ensure all systems support encryption at rest and in transit.
Replace unsupported hardware and software with vendor-supported alternatives.
Ongoing Maintenance:

Schedule regular system reviews (at least annually).

Apply security patches and updates promptly.
Document all changes and maintain an IT asset inventory.
Budget-Friendly Tip:
- Look into nonprofit discounts from major tech providers (e.g., TechSoup, Microsoft, Google) to reduce upgrade costs.

How To - What Are SPF, DKIM, and DMARC—and Why Do They Matter?

One of the most effective ways to protect against email spoofing and phishing is by using email authentication protocols:

SPF (Sender Policy Framework): Verifies that the email is sent from an authorized server.
DKIM (DomainKeys Identified Mail): Adds a digital signature to emails, proving they haven’t been altered in transit.
DMARC (Domain-based Message Authentication, Reporting & Conformance): Tells receiving servers what to do if an email fails SPF or DKIM checks—and provides reports on suspicious activity.

Together, these protocols help ensure that emails claiming to come from your parish or school are actually legitimate. Implementing them can significantly reduce the risk of attackers impersonating trusted staff or clergy.

Establish Incident Response Plans and Conduct Regular Security Drills

Why It’s Important:

A well-prepared response can minimize damage, reduce downtime, and protect sensitive data during a cyber incident.
Drills help ensure that everyone knows their role and can act quickly under pressure.

Key Elements of an Incident Response Plan:

Roles and responsibilities: Who does what during an incident (e.g., IT lead, communications, legal, leadership)?
Detection and reporting: How to recognize and report suspicious activity.
Containment and recovery: Steps to isolate affected systems and restore operations.
Communication protocols: Who needs to be informed (e.g., staff, parishioners, parents, law enforcement)?
Post-incident review: Analyze what happened, what worked, and what needs improvement.

Security Drills:

Conduct simulated phishing attacks to test staff awareness.
Run tabletop exercises where teams walk through a mock cyberattack scenario.
Review and update the plan after each drill to reflect lessons learned.

Documentation and Accessibility:

Keep the plan written, up-to-date, and easily accessible—both digitally and in print.
Ensure key contacts and emergency procedures are clearly listed.
Bonus Tip:
- Partner with your archdiocese IT team or a local cybersecurity consultant to help design and evaluate your plan.

How To - Free Security Awareness Resources

Cybersecurity & Infrastructure Security Agency (CISA)

Website: cisa.gov
Offers free toolkits, posters, videos, and training modules.
Great for building a basic awareness program for staff and volunteers.
Look for their “Stop.Think.Connect.” campaign materials.

2. National Cybersecurity Alliance (NCA)

Website: staysafeonline.org
Provides free tip sheets, infographics, and training guides.
Especially useful during Cybersecurity Awareness Month (October).

3. Google for Nonprofits

Website: google.com/nonprofits
Offers free access to Google Workspace and security best practices.
Includes admin tools to enforce MFA and monitor suspicious activity.

4. Microsoft Security for Nonprofits

Website: nonprofit.microsoft.com
Offers free or discounted Microsoft 365 licenses with built-in security tools.
Includes security training videos and admin guides.

5. KnowBe4 Free Tools

Website: knowbe4.com/free-tools
Offers free phishing tests, password tools, and awareness posters.
Paid plans are available, but many tools are free and easy to use.

6. TechSoup

Website: techsoup.org
Offers discounted software, including security tools and training.
Occasionally hosts free webinars on cybersecurity for nonprofits.

Getting Started with AOS Guardian

Getting started with AOS Guardian begins with understanding that it is a cybersecurity framework and standard, not just a single tool. It is designed to guide parishes, schools, and ministries in building a secure, resilient digital environment using a consistent and layered approach to protection.

1. Understand the AOS Guardian Approach

AOS Guardian is built on a “defense in depth” model—meaning multiple layers of security work together to protect systems, users, and data. This includes identity protection, device security, monitoring, backup, and user awareness.

Rather than relying on a single solution, AOS Guardian ensures your organization has the right combination of controls, policies, and practices in place to reduce risk and respond effectively to threats.

2. Assess Your Current Environment

Begin by evaluating your existing technology environment. This includes:

Email and collaboration platforms (e.g., Microsoft 365 or Google Workspace)
User accounts and access controls
Devices (computers, mobile devices)
Backup and recovery capabilities
Current security tools and configurations

The goal is to identify gaps between your current setup and the AOS Guardian standards.

3. Choose an Implementation Path

Organizations can adopt AOS Guardian in one of two ways:

Adopt the AOS Guardian platform through an approved vendor
Implement an equivalent solution that meets or exceeds AOS Guardian requirements

In either case, the solution must align with the framework’s core principles—layered security, continuous monitoring, and coordinated response.

4. Establish Core Security Controls

As you implement AOS Guardian, ensure the following foundational elements are in place:

Multi-Factor Authentication (MFA) for all users
Secure device management for Windows, Mac, and mobile devices
Endpoint protection against malware and ransomware
Continuous monitoring and threat detection
Cloud backup and restore capabilities
Access controls and conditional access policies

These controls form the baseline for a secure environment and help reduce exposure to common attack methods.

5. Engage Training and Awareness

Technology alone is not enough. AOS Guardian requires that staff and volunteers are trained to recognize and respond to cyber threats.

Security awareness training should cover:

Phishing and social engineering
Password security and account protection
Safe handling of sensitive information

Building a culture of awareness is critical, as human error remains one of the leading causes of security incidents.

6. Implement Monitoring and Response Processes

AOS Guardian emphasizes ongoing vigilance, not one-time setup. Organizations should establish:

Daily review of security alerts
Regular analysis of threats and trends
Defined incident response procedures
Clear communication channels for reporting incidents

This ensures that threats are detected early and addressed quickly.

7. Plan, Deploy, and Validate

Work with your internal team or an approved partner to:

Develop a migration or implementation plan
Deploy required security tools and policies
Test controls and validate compliance
Ensure systems are properly configured and monitored

A structured rollout helps minimize disruption and ensures all requirements are met.

8. Maintain and Improve Over Time

AOS Guardian is an ongoing commitment. Organizations are expected to:

Regularly review and update security policies
Monitor system health and compliance
Conduct periodic security assessments
Stay current with emerging threats and best practices

Cybersecurity is constantly evolving, and maintaining a strong posture requires continuous improvement.

Can we use Google Classroom with AOS Guardian?

Google Classroom can be used within an AOS Guardian-aligned environment, provided it is implemented and managed in a way that meets AOS Guardian security standards.

AOS Guardian does not prohibit specific tools; instead, it defines how technologies must be secured. Any application—including Google Classroom—must be integrated into a broader security framework that includes identity protection, access controls, monitoring, and data protection.

To align Google Classroom with AOS Guardian, organizations should ensure:

Secure Identity Integration – User accounts are protected with strong authentication, including multi-factor authentication (MFA), and managed through a centralized identity system where possible.
Access Controls – Only authorized users (students, teachers, staff) can access classroom data and resources.
Device Security – Devices used to access Google Classroom meet security and compliance standards.
Data Protection – Sensitive information shared through Classroom is appropriately governed, stored, and backed up where required.
Monitoring and Visibility – Activity is logged and monitored to detect suspicious behavior or unauthorized access.

If Google Classroom is part of your environment, it must be included in your overall AOS Guardian security posture—not treated as a standalone system.

The key principle is that all tools used within the Archdiocese must operate within a secure, managed, and monitored environment, regardless of vendor or platform.

AOS Guardian - Authorized Vendors

Vendors offering AOS-Guardian or Equivalent Platforms

CRD Solutions - 425) 329-6414 or email info@crdsolutions.org
Johnson CN - 888-800-0454 - support@johnsoncn.com
O'Brien Business GRP Corp - (425)233-6994 or Email: techsupport@obrienbusinessgroup.com
KellyCreate - (360) 920-3858 or Email: michelle.jones@kelleycreate.com
Plan Tech - https://plan.tech or email Preston Lewis plewis@plan.tech or call 206.265.9405

Incident Reporting

AOS Guardian Frequently Asked Questions

What is AOS Guardian?

AOS Guardian is a cybersecurity framework established by the Archdiocese of Seattle that defines how parishes, schools, and ministries should protect their digital environments using a layered, defense-in-depth approach. [\

Is AOS Guardian a product or a platform?

AOS Guardian is **not just a single product**—it is a **design standard and framework**. Organizations may adopt the AOS Guardian platform or implement an equivalent solution that meets its requirements.

Why is AOS Guardian required?

Cyberattacks targeting parishes and schools have become more frequent and sophisticated, including phishing, credential theft, and impersonation. AOS Guardian ensures consistent, stronger protection across all organizations.

Who must adopt AOS Guardian?

All parishes, schools, and ministries within the Archdiocese are required to implement AOS Guardian or an approved equivalent solution to meet security standards.

Can we use our current IT provider or tools?

Yes—organizations may continue using their existing tools **if they meet or exceed AOS Guardian requirements** and participate in the broader security initiative (including incident coordination). Please review the list of authorized vendors

What are the core components of AOS Guardian?

AOS Guardian is based on key security capabilities, including:

Multi-factor authentication (MFA)
Endpoint/device protection
Centralized management
Continuous monitoring and response
Cloud backup and recovery
Security awareness training

What does “defense in depth” mean?

Defense in depth is a layered security approach where multiple protections work together. If one control fails, additional layers help prevent or limit an attack.

Does AOS Guardian replace Microsoft 365 or Google Workspace?

No. AOS Guardian **builds on top of existing platforms** like Microsoft 365 or Google Workspace by adding advanced security, monitoring, and management capabilities.

What role does staff training play?

Staff training is a critical part of AOS Guardian. Users must be trained to recognize phishing, scams, and other threats, as human error is a leading cause of cybersecurity incidents.

What happens if we don’t adopt AOS Guardian?

Failure to adopt a compliant solution increases exposure to cyber risk and may result in non-compliance with Archdiocesan IT standards.

Is AOS Guardian managed centrally?

AOS Guardian can be implemented either:

* Through a **centrally supported or vendor-managed approach

Independently, where the organization assumes responsibility for ongoing management and compliance

How long does it take to implement AOS Guardian?

Implementation timelines vary based on the current environment, but organizations are expected to follow Archdiocesan timelines and complete adoption within the defined migration period.

What are the benefits of AOS Guardian?

Stronger protection against cyber threats
Reduced risk of financial and data loss
Centralized visibility into security posture
Simplified administration
Alignment with Archdiocesan standards and best practices

Where can we get help getting started?

Organizations should work with an **approved vendor or qualified IT partner** to assess their environment, develop a plan, and implement required controls in alignment with AOS Guardian.

Parish & School Resources

How-To: Hardening Google Workspace

This document is a practical reference for hardening Google Workspace. It covers two related but distinct concerns: protecting Gmail and core Workspace accounts against credential phishing, OAuth abuse, and session-token theft (Sections 1 through 9); and hardening Google Classroom against student-safety risks, roster integrity issues, and unauthorized access (Section 10). It is written for an administrator who already manages a Workspace tenant and is comfortable in the Admin console.

Modern attacks against Workspace rarely break encryption or exploit Google directly. They steal a session cookie, trick a user into granting an OAuth scope, or social-engineer the help desk into resetting an account. Classroom adds a different threat model on top of that: minors and adult learners share an environment where the consequences of a misconfiguration are not just data loss but also exposure of vulnerable users. The controls below are organized so the highest-impact, lowest-friction items come first.

1. Eliminate password-only access

Stolen passwords are the entry point for the majority of account takeovers. The goal of this layer is to make a stolen password insufficient on its own.

1.1 Enforce 2-Step Verification org-wide

In the Admin console, navigate to Security → Authentication → 2-Step Verification and set enforcement to On for all organizational units. Allow a short grace period for enrollment, then disable the grace exception.

1.2 Require phishing-resistant MFA

SMS codes and TOTP authenticator apps are vulnerable to real-time phishing proxies (for example Evilginx) that capture both the password and the resulting session cookie. Phishing-resistant MFA prevents this because the authentication is bound to the origin domain.

Issue FIDO2 hardware security keys (YubiKey, Titan, Feitian) to all administrators and high-value accounts.
Enable platform passkeys for general staff where hardware keys are impractical.
Under 2-Step Verification settings, set the Allowed methods to Only security key (or security key plus passkey) for the Admins OU.
Distribute at least two keys per administrator to avoid lockout if one is lost.

1.3 Enroll high-risk accounts in the Advanced Protection Program

APP is Google's hardened mode. It enforces security keys, blocks most third-party app access by default, adds extra download scanning, and slows account recovery to defeat help-desk social engineering. Recommended for super admins, finance staff, and any account with broad data access.

2. Shorten and constrain sessions

Once an attacker steals a session cookie or refresh token, MFA is already past. The defenses in this section reduce how long a stolen token remains useful and add re-evaluation checks.

2.1 Reduce web session duration

Admin console → Security → Google session control. The default is 14 days, which is far too long for sensitive accounts.

General users: 8 to 12 hours.
Administrators: 1 to 4 hours.
Apply per OU so reduced lifetimes target privileged accounts first.

2.2 Enable Context-Aware Access

Context-Aware Access evaluates device posture, IP, and location on every sensitive action, not just at login. A token exfiltrated to an attacker's machine in another country fails the context check even though the cookie is technically valid.

Create access levels based on managed-device status, IP range (corporate egress, VPN), and country.
Bind Gmail, Drive, and Admin console to those access levels.

2.3 Require reauthentication for sensitive admin actions

In the admin console, enable the Require security key setting for sensitive admin actions. This forces a hardware-key touch for actions such as suspending users, modifying SSO, or exporting data, even within an active admin session.

3. Lock down OAuth

When people say "Gmail token theft" they often mean OAuth refresh tokens granted to third-party apps, or malicious OAuth apps tricking users into granting gmail.readonly or gmail.send scopes. This is the consent-phishing attack pattern, and it bypasses MFA entirely because the user genuinely approves the grant.

3.1 Block unconfigured third-party apps

Admin console → Security → API controls → App access control. Set unconfigured third-party apps to Blocked, then explicitly trust the OAuth clients your organization actually uses. After this change, a user clicking through a phishing OAuth consent screen will be unable to grant scopes to an unknown app.

3.2 Restrict Gmail and other sensitive scopes

Treat the Gmail, Drive, and Calendar scopes as restricted. Allowlist only the specific OAuth client IDs that legitimately need them. Unrestricted scopes (profile, email) can have a broader allowlist.

3.3 Audit existing OAuth grants

In the audit log, filter by Token events to see every OAuth grant, including scope and client ID.
Review at least monthly for unfamiliar client IDs, especially those holding gmail.modify, gmail.send, or full_access scopes.
Revoke unrecognized grants org-wide from the API controls page.

3.4 Treat refresh tokens as long-lived secrets

OAuth refresh tokens for server-to-server integrations can persist for months. For internal integration platforms that use Gmail or Workspace APIs, store refresh tokens in a secrets manager rather than environment files, rotate the underlying client secret on a defined schedule, and alert when a refresh token is used from an unexpected IP.

4. Disable or constrain legacy protocols

IMAP, POP, and SMTP relay with app passwords are common footholds because they bypass MFA. Auto-forwarding and inbox filters are classic post-compromise persistence mechanisms.

Admin console → Apps → Google Workspace → Gmail → End User Access. Disable POP and IMAP unless a documented workflow requires them.
Where IMAP/POP must remain, scope to specific accounts and require OAuth (XOAUTH2) instead of app passwords.
Disable user-controlled auto-forwarding to external addresses (Admin console → Apps → Gmail → End User Access → Automatic forwarding).
Alert on the creation of any new mail filter that forwards externally or auto-deletes incoming mail.

5. Detection and response

Prevention will eventually fail. Instrument the environment so a compromise is detected in hours, not weeks.

5.1 Stream audit logs

Export Workspace audit logs (Login, Token, Admin, Gmail, Drive) to a SIEM or to BigQuery with alerting. Key signals to watch for:

New OAuth grants to risky scopes (gmail.modify, gmail.send, full mailbox access).
Login from a new ASN or country, especially for admins.
New mail filters that forward externally or auto-delete.
Mass message or file deletion events.
IMAP or POP enable events at the user level.
Admin role grants and changes to super admin membership.
Any sign-in to a break-glass account.

5.2 Configure Alert Center rules

Enable the built-in alerts for suspicious login, leaked password, government-backed attack warnings, and suspicious programmatic access. Route them to a monitored mailbox or ticketing system; default delivery to a single admin inbox is fragile.

5.3 Enable enhanced safe browsing and security sandbox

Admin console → Apps → Gmail → Safety. Turn on attachment sandboxing, link scanning, and external image protection.

6. Harden the inbound mail surface

Most credential and OAuth phishing arrives by email. Reducing the volume that lands in inboxes is straightforward and high-leverage.

Publish DMARC at p=reject with aligned SPF and DKIM. Begin with p=none, monitor reports, then move to quarantine and finally reject.
Enable inbound DMARC enforcement so the tenant rejects spoofed mail from external domains that publish DMARC.
Block executable and script attachments at the gateway.
Enable the external sender warning banner. The UX nudge has a measurable effect on phishing click rates.
Configure MTA-STS and TLS-RPT to prevent downgrade attacks on SMTP delivery.

7. Endpoint hygiene

Tokens live on devices. If the device is compromised, the token is compromised.

Enroll all devices in MDM. Endpoint verification is a minimum; full management is preferred for admin workstations.
Require disk encryption and a screen-lock policy.
Use Context-Aware Access to gate Workspace access on managed-device status.
Pilot Chrome Enterprise device-bound session credentials (DBSC). DBSC cryptographically binds the session cookie to the device TPM, so an exfiltrated cookie is useless on the attacker's machine. This is the emerging answer to infostealer malware.

8. Account recovery and the help desk

This is the soft underbelly. A large share of recent high-profile Workspace takeovers went through the help desk, not the login page.

Remove SMS as a recovery factor for admin and high-value accounts.
Require verified identity (in person or video with government ID) for password and MFA resets on privileged accounts.
Document the procedure, train help-desk staff, and rehearse it. Attackers specifically target organizations whose help desk will reset on a convincing phone call.
Maintain at least two break-glass super admin accounts with hardware keys stored physically offline. Alert on every sign-in to them.

9. Google Vault for preservation and forensics

Vault is widely mis-sold as a backup tool. It is more accurately described as a legal-hold and eDiscovery layer that survives user deletion. In a security context, Vault hardens the tenant against destructive post-compromise behavior and provides ground truth for incident response.

9.1 What Vault helps with

Mass deletion or wiper attacks. A compromised account that empties the mailbox cannot reach Vault-retained copies. Without Vault, deleted Gmail is gone after the 30-day Trash window.
Forensic reconstruction. Audit logs tell you what happened; Vault search lets you see the actual content of messages the attacker read, sent, or forwarded.

9.2 What Vault does not help with

Exfiltration prevention. Vault is read-after-the-fact. It preserves evidence but does not stop a forwarding rule from sending 50,000 messages out. That is a DLP problem.
Real-time detection. Vault does not alert. It is searched after a compromise is suspected.
Operational backup. Vault does not provide point-in-time restore, folder structure recovery, or Drive permission rollback. For that, run a third-party backup product (Spanning, Backupify, Afi, Datto) alongside Vault.

9.3 Configuring Vault for security, not just compliance

Set default retention rules that survive user deletion. A typical pattern is indefinite or multi-year retention on Gmail and Drive for the full organization, or at minimum for admins and high-value accounts.
Separate the Vault admin role from the super admin role. A compromised super admin should not be able to also wipe the evidence trail. Assign Vault admin to a small, distinct set of accounts protected by hardware keys.
Add "place legal hold on affected account" as an early step in the incident-response runbook, before credential reset. A hold overrides retention rules and user deletions absolutely.
Stream Vault audit events (search, export, hold creation, hold removal, retention rule changes) to the SIEM. Removal of a retention rule should be a high-severity alert.
Verify Chat retention. History-on versus history-off spaces and ephemeral messages have historically had quirks; confirm the rules cover the spaces that matter.
Confirm licensing tier. Vault is included with Business Plus, Enterprise, Education Standard/Plus, and Frontline Standard, or available as an add-on. Coverage gaps create the exact evidentiary holes attackers exploit.

9.4 Vault and third-party backup are complementary

For an organization with active operational data, run both. Vault preserves messages and files for legal and forensic purposes and cannot be reached by a user-level attacker. A third-party backup product gives you point-in-time restore for the operational scenarios Vault handles poorly: ransomware-style modification, accidental mass change, Drive permission corruption.

10. Hardening Google Classroom

Google Classroom inherits the account-level protections from Sections 1 through 9, but adds a distinct threat model. The risks shift from "attacker steals an admin's token" to "a minor is exposed to inappropriate content," "an outsider enrolls in a class," "a student impersonates a teacher," or "rosters drift out of sync with the source of truth." This section assumes Classroom is in production with a mixed K-12 and adult-learner population, which is the most demanding configuration.

Two cross-cutting principles apply throughout: minors require stricter defaults than adults, and Classroom is only as safe as the underlying Workspace account hygiene. If a student account has a weak password or no MFA, no Classroom-specific control will compensate.

10.1 Account architecture: separate OUs for distinct populations

Before any Classroom-specific setting, segment users into organizational units that reflect their actual population. A common pattern for a mixed environment:

Students / K-12 (minors) — strictest defaults, age-appropriate restrictions.
Students / Adult learners (faith formation, RCIA, continuing education) — adult defaults, but still constrained sharing.
Teachers / Catechists — verified educator role, broader Classroom permissions.
Staff / Admins — standard Workspace controls from earlier sections.

OU-level segmentation is the foundation. Almost every Classroom control below applies per OU, and getting this wrong is the single most common cause of misconfiguration.

10.2 Restrict who can create and teach classes

Admin console → Apps → Additional Google services → Google Classroom → General settings. Set the teacher permissions explicitly:

Set "Who can create classes" to Verified teachers only. This prevents a student account, a compromised account, or an outsider with a domain email from spinning up a class and enrolling minors.
Add legitimate teachers and catechists to the verified-teacher group. The group should be managed centrally, not self-service.
Review the verified-teacher group at the start of each term and after staff departures. A former teacher retaining class-creation rights is a real risk.
Set "Class membership" to Users in your domain only unless there is a documented reason to allow external participants. External membership is a common path for unauthorized adults to access classes containing minors.

10.3 Guardian email summaries (K-12)

For minor students, enable guardian email summaries. This sends parents and guardians a periodic digest of upcoming work, missing assignments, and class activity, and serves both an educational purpose and a child-safety oversight function.

Admin console → Classroom settings → Guardian access. Turn on guardian email summaries.
Designate which staff can invite and manage guardians. Restricting this to a small group prevents a compromised teacher account from removing guardian oversight at scale.
Audit guardian invitations periodically. The audit log records guardian add and remove events.
Do not enable guardian summaries on the adult-learner OU; it is unnecessary and creates a privacy issue.

10.4 Class codes, invitations, and enrollment integrity

Classroom supports three enrollment paths: class codes, direct invitations, and SIS-driven roster sync. Each has tradeoffs.

Class codes are convenient but trivially shareable. A code posted on social media or forwarded by a student lets anyone with a domain account join. For minor students, prefer direct invitation or SIS sync. If class codes are used, instruct teachers to reset the code after enrollment closes (the Classroom UI supports this).
Direct invitations are tightly scoped but rely on the teacher to maintain accuracy.
SIS-driven sync (via Clever, Infinite Campus, PowerSchool, or Classroom's own roster import) is the gold standard for K-12. The student information system becomes the source of truth, and Classroom rosters update automatically when enrollments change. This eliminates the most common roster-drift problem: students who left the program but still have access to materials and discussion.

Recommended posture: SIS sync for K-12 classes; direct invitation for adult-learner cohorts; class codes only for short-lived workshops with adult participants.

10.5 Co-teacher and ownership controls

Classes can have multiple teachers, and a co-teacher promoted to primary teacher inherits ownership of all class materials. This is a useful continuity feature and a real takeover risk.

Require at least one verified administrative co-teacher (a department head, principal, or DRE) on every class containing minors. This person should not be the same individual as the primary teacher. The purpose is oversight, not co-instruction.
Document a procedure for transferring class ownership when a teacher departs, rather than allowing the departing teacher to make the transfer themselves.
In the audit log, monitor Classroom events for ownership transfer, especially transfers initiated outside business hours or by an account that recently failed login attempts.

10.6 Communication and content controls

Classroom communication happens in three places: the class stream (public to the class), private comments on assignments (teacher-student only), and Google Chat / Meet if integrated. The risk profile differs for each.

Class stream. Set "Students can post and comment" to Only teachers can post for K-12 OUs by default; teachers can relax this per class when appropriate. Allowing student posts on the stream is the most common path for inappropriate content to reach the whole class.
Private comments. These are the highest-risk channel for K-12 because they create a direct one-to-one teacher-student communication path with no automatic visibility to administrators. They cannot be disabled in Classroom, but they are retained in Vault if Classroom data retention is configured (see 10.10). Train teachers that private comments are an official record, and that students should not be asked to discuss anything outside instructional content there.
Chat and Meet integration. For K-12, restrict Chat to within-domain only, disable external chat, and disable direct messages between students where the population permits (Admin console → Apps → Chat). For Meet, restrict who can create meetings, require the host to admit external participants, and disable recording for student accounts unless legally required.

10.7 Originality reports, plagiarism, and AI content

Classroom's originality reports check student work against web sources and (for paid Education tiers) the school's own corpus of past submissions. This is primarily an academic-integrity tool, but it has a security-adjacent benefit: it helps surface accounts being used by someone other than the enrolled student.

Enable originality reports for the teacher OU.
For Education Plus tenants, enable the school-corpus matching feature, which detects submissions copied from other students.
Document a policy on AI-generated content and communicate it to students and adult learners. Classroom does not currently provide a reliable AI-detection feature, so policy and assignment design matter more than tooling here.

10.8 Third-party app and add-on governance

Classroom supports add-ons (turnkey integrations with tools like Khan Academy, Pear Deck, EdPuzzle) and links to third-party assignment tools via OAuth. Each add-on or linked tool requests scopes against student accounts, which means the OAuth governance from Section 3 applies directly.

In API controls, treat student OUs as the most restrictive: block unconfigured third-party apps entirely, and explicitly trust only the add-ons your educators actually use.
Review add-ons annually. Educational tools come and go, and an abandoned vendor with retained OAuth grants is a stale data-access path.
For minor students, verify each add-on vendor's COPPA / FERPA / state privacy posture before approval. The Workspace admin is the data-protection accountable party here, regardless of the vendor's claims.
Disable user-installed Marketplace apps for student OUs. Allow them only for teachers, and only after admin review.

10.9 Student-account hygiene specific to Classroom

Several account-level controls deserve specific attention for student accounts:

Disable Gmail external mail for K-12 student OUs unless required. Many districts run student accounts in domain-only mail mode, which dramatically reduces phishing exposure.
Disable Drive external sharing for K-12 students. Allow internal sharing only, with a documented exception process.
Restrict YouTube to Strict or Moderate restricted mode at the OU level.
Disable Google Photos and consumer-app access for student OUs.
Enforce the password and MFA requirements from Section 1 on student accounts. Passkeys are appropriate for students 13 and older; for younger students, follow district policy on shared-device login flows.
For shared-device classrooms (Chromebook carts), use managed guest sessions or ephemeral mode so a student session does not persist tokens on the device.

10.10 Audit, retention, and incident response for Classroom

Classroom-specific events are recorded in the Workspace audit log under Classroom log events. The retention and forensic considerations from Section 9 apply, with some Classroom-specific signals worth alerting on:

New class created by an account not in the verified-teacher group (indicates misconfiguration or a compromised teacher account).
Bulk student enrollment outside SIS sync windows.
External user added to a class containing minors.
Co-teacher added or ownership transferred outside business hours.
Assignment or material deleted in bulk (potential evidence destruction).
Guardian removed from a student account (potential evasion of oversight).

Configure Vault retention rules to cover Classroom data (announcements, assignments, submissions, comments). Vault retention for Classroom is configured separately from Gmail and Drive — verify it explicitly. For K-12, multi-year retention aligned with district record-retention policy is typical.

Add Classroom-specific steps to the incident-response runbook: place a legal hold on the affected teacher and student accounts; preserve guardian email summary records; export the relevant class stream and private comments; coordinate with the school principal or DRE before suspending a teacher account, since suspension makes class materials inaccessible to students mid-term.

10.11 Reporting and abuse workflow

A documented, low-friction reporting path is itself a security control. Students, parents, and adult learners need a way to report inappropriate content or behavior that does not depend on the alleged actor.

Publish a Classroom-specific reporting email or form that routes to IT and the appropriate safe-environment officer (for an archdiocesan environment, this typically means the Office for Safe Environment or equivalent).
Train teachers and catechists on mandatory-reporting obligations. Classroom communications are subject to the same reporting laws as in-person interactions.
Document the IT preservation procedure that runs in parallel with any safe-environment investigation: legal hold, audit-log export, communication with Vault admin.
Test the workflow at least annually with a tabletop exercise.

11. Suggested rollout order

If implementing from a low baseline, the following sequence delivers the largest risk reduction first. Account-level controls (Sections 1 through 9) are prerequisites for Classroom hardening — Classroom controls assume the underlying account is already protected.

Continues from : 9.3 Configuring Vault for security, not just compliance

Hardware keys for all super admins and break-glass accounts (week 1).
Phishing-resistant MFA for all admins and high-value users; Advanced Protection Program enrollment (weeks 1 to 2).
Block unconfigured third-party OAuth apps; audit and clean up existing grants (week 2).
Reduce session lifetimes; enable Context-Aware Access (week 3).
Disable IMAP/POP and external auto-forwarding; tighten DMARC to p=reject (weeks 3 to 4).
Stream audit logs to SIEM; configure Alert Center rules — including Classroom-specific signals (week 4).
Configure Vault retention rules (Gmail, Drive, and Classroom) and separate Vault admin role; rehearse hold-on-compromise procedure (weeks 5 to 6).
Classroom OU segmentation; restrict class creation to verified teachers; enable guardian summaries for K-12 (weeks 6 to 7).
SIS roster sync for K-12 classes; tighten student-OU defaults (Gmail, Drive, YouTube, add-ons) (weeks 7 to 8).
Document and rehearse the Classroom abuse-reporting and IR workflow with safe-environment staff (week 9).
Help-desk identity verification procedures; pilot/evaluate Chrome Enterprise DBSC (ongoing).

AOS Artificial Intelligence (AI) Guidance

Learning Links

Avoiding Phishing Emails - Poster

Archived Resources

PAA Days 2025 Files

Windows Clients - End of Life (Microsoft)