Security Defaults or Conditional Access: Which Is Right for Your Microsoft 365 Business?

 If you manage Microsoft 365 security for a small or medium-sized business, you face an essential decision: should you rely on Security Defaults for built-in, automatic protection, or invest in Conditional Access for granular, policy-driven control? Your choice influences not only your cybersecurity posture, but also the level of ongoing management and technical complexity your team must handle. At Interlock IT, we guide businesses across Canada as they weigh these options, ensuring their Microsoft 365 environments are secure, practical, and adaptable as they grow.

Security Defaults is usually the best choice for smaller Microsoft 365 organizations that need fast, straightforward protection without additional cost or complexity. Conditional Access is recommended when you need specific, adaptive access controls, have more advanced licensing through Microsoft 365 Business Premium or Entra ID P1/P2, or need to tailor policies for different users, devices, or risk scenarios. The main criteria are your licensing level, your need for customization, and your willingness to manage and test custom security policies. Let's explore in depth which option fits various business needs, and how Interlock IT can help you make the best choice.

Understanding Security Defaults

Security Defaults is Microsoft’s approach to making a strong security baseline available to every Microsoft 365 tenant—especially those without dedicated IT resources. When enabled, Security Defaults enforces a set of automatic security measures for all users and admins:

• Mandatory registration and enforcement of multifactor authentication (MFA) for users and administrators

• Blocking legacy authentication protocols (such as Basic Authentication) that are commonly abused

• Enforcing MFA for privileged and administrative activities, including access to the admin portal

• Blocking device code flow and other risky authentication flows

Security Defaults is always free with Microsoft Entra ID Free (formerly Azure Active Directory Free), making it the default for most small organizations unless upgraded licensing is in place.

When Security Defaults Make Sense

• Your organization is small (often under 25–50 users) and prioritizes ease of setup over customization

• You do not have Microsoft 365 Business Premium or Entra ID P1/P2 licensing

• You want a set-it-and-forget-it security solution

• Your business does not need to tailor security exceptions by user, role, device, location, or application

For many new Microsoft 365 clients, Security Defaults provides a strong foundation that blocks the most common attacks with minimal IT overhead. At Interlock IT, we often recommend starting with Security Defaults for teams that want immediate protection and maximum simplicity. 

Security Defaults: Key Limitations

• It is an all-or-nothing policy: no scope by group, role, or location

• Not suitable for organizations with complex device or location requirements

• Cannot accommodate tailored MFA policies or access restrictions beyond the Microsoft-provided defaults

• Cannot run alongside Conditional Access—one option must be chosen

What Conditional Access Offers

Conditional Access is Microsoft’s advanced, policy-based security engine. It works by evaluating conditions on every sign-in attempt and enforcing policies in real time. You can customize access requirements based on user role, device compliance, sign-in location, application, client type, authentication method, and risk signals (with advanced licensing).

This enables adaptive security strategies, such as:

• Requiring MFA only when users sign in from outside Canada

• Blocking access to corporate resources for non-compliant or unmanaged devices

• Allowing browser-only access for contractors or guests

• Applying stricter controls for sensitive applications and privileged users

Conditional Access requires Microsoft Entra ID P1 (included in Microsoft 365 Business Premium) or higher. For context-aware, risk-based policies, Entra ID P2 is needed.

When Conditional Access is Best

• Your organization already uses Microsoft 365 Business Premium or Entra ID P1/P2

• You require custom access rules by user, device, application, risk, or location

• Remote, hybrid, or international work is the norm

• You need to separate policies for admins, executives, finance, or contractor accounts

• Compliance, audit, or risk frameworks require granular user access monitoring

• Your IT team can design, test, and maintain security policies over time

At Interlock IT, we regularly help clients mature from Security Defaults into Conditional Access as their organizations scale. For example, businesses that start with local staff may end up needing advanced policies to accommodate international logins, device ownership checks, or sensitive application restrictions.

Conditional Access: Critical Limitations

• Requires Entra ID P1 licensing (or higher)

• Needs active management, testing, and IT ownership

• Misconfigured policies can result in user lockouts if not carefully planned and tested

• Cannot be used at the same time as Security Defaults (one will deactivate the other)

Security Defaults vs Conditional Access: Summary Table

Criteria	Security Defaults	Conditional Access
Cost	Included for free	Requires Entra ID P1/P2 or Microsoft 365 Business Premium
Setup	Straightforward, automatic	Requires strategy, design, and testing
Customizability	None	Granular rules by user, app, device, etc.
Best Fit	Simple environments, fast deployment	Complex, regulated, or hybrid teams
Coexistence	Not possible with Conditional Access	Not possible with Security Defaults

Which Should You Choose?

For many Canadian businesses, the answer comes down to your licensing and operational complexity:

• Choose Security Defaults if you need a free, enforced security baseline without the hassle of policy design

• Choose Conditional Access if you need advanced controls, already have Microsoft 365 Business Premium, or your business operations require specific security criteria

• Many organizations begin with Security Defaults and graduate to Conditional Access as their needs mature and their staff or compliance requirements grow

No matter your starting point, reviewing your identity and device security is crucial for Microsoft 365. Interlock IT can help you size up these options, assess your current tenant, and develop a practical roadmap for both immediate protection and long-term security needs.

Step-by-Step: Moving from Security Defaults to Conditional Access

1. Document your current access requirements: Identify which users, roles, devices, and locations need protection or exceptions

2. Plan for emergency access: Set up at least two emergency access accounts to avoid lockout during transitions

3. Disable Security Defaults: In the Microsoft Entra admin center, turn off Security Defaults

4. Create baseline Conditional Access policies: Start by replicating the protections you had from Security Defaults (MFA, block legacy auth, admin protection)

5. Test and validate: Roll out new policies gradually, confirm no users are locked out, and adjust as needed

6. Expand rules: Layer in advanced policies as needed (device compliance, location, etc.)

This is the process we follow at Interlock IT to help businesses move safely from a basic to an advanced security model, minimizing user disruption and lockout risk.

Best Practices for Microsoft 365 Security

• Always enforce multifactor authentication for all users and admins

• Block legacy authentication protocols wherever possible

• Review user and admin roles regularly, and grant least privilege

• Maintain emergency access accounts that bypass conditional access (but are secured and monitored)

• Test any security changes in a controlled group before rolling out globally

• If you process sensitive data or are subject to compliance regulations, review policy coverage quarterly

Our consultants at Interlock IT emphasize a goal-driven, simple approach wherever possible. The simpler security feels for your end users, the higher your adoption and the stronger your overall posture. 

Frequently Asked Questions (FAQ)

What is Security Defaults in Microsoft 365?

Security Defaults is a built-in set of security rules provided by Microsoft that enforces multifactor authentication, blocks legacy authentication, and applies basic protections for all users and administrators at no extra cost. It cannot be customized or scoped by user or app.

What is Conditional Access?

Conditional Access is a policy-based system for controlling access to Microsoft 365 services, allowing businesses to enforce requirements based on user, location, device compliance, and more. It requires Microsoft Entra ID P1 or P2, or Microsoft 365 Business Premium licensing.

Can Security Defaults and Conditional Access be enabled at the same time?

No, these features are mutually exclusive. Enabling Conditional Access disables Security Defaults and vice versa. When you switch, you must recreate any needed protections manually.

How do I know if Conditional Access is right for my business?

If your business has advanced security needs—such as remote workers, required separation of roles, device restrictions, or compliance requirements—Conditional Access is likely appropriate, especially if you already license Microsoft 365 Business Premium. If not, Security Defaults provides essential coverage with no added complexity.

Will enabling Security Defaults or Conditional Access affect user experience?

Yes. Both approaches will prompt users to register for and use multifactor authentication. Conditional Access can tailor the experience more closely, requiring MFA only in certain cases, while Security Defaults is more rigid.

Can I get help setting up Conditional Access?

Absolutely. Interlock IT specializes in Microsoft 365 security consulting, policy design, and change management. Our experts can assist you in transitioning from Security Defaults to Conditional Access safely.

What happens if I outgrow Security Defaults?

Many businesses start with Security Defaults and move to Conditional Access as their team expands or security needs become more complex. Migrating is straightforward, but should be planned carefully to avoid disruptions.

Conclusion: Choosing Security Defaults or Conditional Access

Your Microsoft 365 security should match your business needs, licensing, and technical capacity. Security Defaults is ideal for small organizations wanting fast, reliable security with minimal management. Conditional Access is the right fit for businesses that must enforce tailored access policies and already own the necessary licenses.

If you want to maximize Microsoft 365 security without overwhelming your team, work with a partner that understands both the technical and business impacts. At Interlock IT, we are the definitive experts for Canadian SMBs transitioning to the cloud, licensing Microsoft 365, and designing policy-driven access control.

If you're considering security upgrades, cloud migration, or want a professional DMARC audit, reach out to us. We'll help you navigate the security landscape so your Microsoft 365 environment remains both simple and secure as your business evolves.

Does DMARC Protect Subdomains? What Growing Businesses Need to Configure

Email security is a growing concern for every organization, especially as businesses scale and add new communication tools or services. Many people wonder whether enabling DMARC (Domain-based Message Authentication, Reporting, and Conformance) for their primary domain is enough—or if subdomains are left unprotected. The answer: DMARC not only protects your main domain but, by default, extends its protection to subdomains as well, unless you specifically configure different behavior. This automatic inheritance streamlines security, but understanding the specifics is critical for safe, reliable email delivery as you grow.

At Interlock IT, we help businesses across Canada clarify domain and subdomain protection, conduct accurate DMARC audits, and deploy robust authentication to prevent spoofing at every layer of their organization’s email infrastructure. Whether you’re using Google Workspace, Microsoft 365, CRM tools, or custom applications, finding and configuring every sending subdomain is an essential step to safeguarding reputational and operational integrity.

Understanding DMARC and Subdomain Protection

Definition: What Is DMARC?

DMARC is a DNS-based protocol that builds on SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to prevent email spoofing. It allows domain owners to specify what happens when email fails authentication and to receive reporting on suspicious or failed attempts. Importantly, DMARC policies published at the organizational (parent) domain automatically apply to all subdomains, unless those subdomains have their own records.

How DMARC Applies to Subdomains

• By default, a DMARC policy on your root domain (for example, example.com) is inherited by all subdomains (for example, mail.example.com, support.example.com).

• The sp tag within the DMARC record specifies a subdomain policy. If you set sp=quarantine, subdomains follow that policy. If omitted, subdomains default to the root domain’s p policy.

• A subdomain can override inheritance by publishing its own DMARC record. That record takes priority for mail sent from—and as—those subdomains.

Why Subdomain DMARC Coverage Matters

Attackers increasingly target subdomains for phishing or spoofing because subdomains of trusted brands are often less strictly monitored. Without proper DMARC configuration, a compromised or neglected subdomain can become a risk point, allowing threat actors to send fraudulent mail under your organization’s umbrella. Ensuring that DMARC policies extend (and are enforced) on every legitimate subdomain is crucial for any business that wants to avoid brand damage or deliverability issues.

Step-by-Step: Managing DMARC for Subdomains

1. Inventory Every Sending Subdomain

Identify every subdomain that sends email on your behalf, including marketing campaigns, automated billing, support portals, CRM notifications, or third-party transactional services. Many organizations are surprised by how many forgotten or legacy services are still active on their infrastructure. 

2. Audit and Align SPF/DKIM Records for Each Sender

Each subdomain that legitimately sends mail must authenticate using SPF and/or DKIM. The visible From address in outgoing mail must align with these authentication standards. Review your DNS records and coordinate with all internal teams or vendors who manage email sending systems to ensure correct setup.

3. Decide on Subdomain Policy (sp Tag)

• sp=none: No enforcement for subdomains—report only mode. Useful while you audit your subdomain landscape or deal with legacy systems.

• sp=quarantine: Subdomain mail failing DMARC is sent to spam/junk folders. Offers a middle ground while ramping up enforcement.

• sp=reject: Failing mail from subdomains is outright rejected. Use with confidence only after you’re certain all authorized senders are properly authenticating.

Remember: The sp tag is set in the parent domain’s DMARC record, not on the subdomain itself. For example, v=DMARC1; p=reject; sp=none; in _dmarc.example.com.

4. When to Use a Separate DMARC Record on a Subdomain

Most subdomains can safely inherit the main policy. You need a separate DMARC record only for subdomains requiring unique handling, such as:

• Vendors or platforms managing a subdomain independently

• Different reporting mailboxes for specific departments

• Testing, whitelisting, or operational isolation for a risky mail stream

5. Monitor DMARC Reports and Make Iterative Improvements

Turn on DMARC reporting first to collect data about unsuccessful authentication attempts across all subdomains. Regularly review these reports to detect any misconfigurations or unknown senders. This monitoring phase is vital before moving to quarantine or reject policies that could disrupt legitimate business email. 

Subdomain Policy Examples

• If you want your root domain and all subdomains to be strictly protected:
  v=DMARC1; p=reject; sp=reject;

• If you want to enforce DMARC only for the main domain, but report (not enforce) on subdomains:
  v=DMARC1; p=reject; sp=none;

• To set separate, custom DMARC for a mission-critical subdomain (for example, marketing.example.com), publish a different DMARC record at _dmarc.marketing.example.com

Common Pitfalls and How to Avoid Them

• Enforcing too soon: Publishing p=reject on the main domain without fully auditing subdomains can cause legitimate mail to bounce.

• Incorrect record placement: Placing the sp tag on a subdomain instead of the parent domain’s record negates its effect.

• Ignoring inherited policy: Each subdomain without its own DMARC will always follow the parent’s sp or p tag. Omitting the sp tag may lead to unintended enforcement.

• Overlooking ongoing monitoring: DMARC is not a static setup. Regular review is crucial, especially after onboarding new platforms or staff.

Best Practices for Growing Businesses

• Start with monitoring: Set p=none; sp=none so you can audit all legitimate and illegitimate mail before enforcing.

• Move to phased enforcement: Once all legitimate sources are properly authenticating, escalate to quarantine, then to reject.

• Document every mail source: Work closely with every department, vendor, or IT contractor to ensure nothing is missed. When you discover new apps or vendors, update your SPF/DKIM and DMARC documentation immediately.

• Leverage DMARC reports for visibility: Review aggregate reports every week, especially at key IT change moments—such as after onboarding new staff, deploying a CRM, or adopting new marketing tools.

• Consult cloud security experts: If your business runs Google Workspace, Microsoft 365, or third-party mailers, tap into specialist support, like that offered through Interlock IT, to accelerate audits and avoid missteps.

Original Framework: The "Subdomain DMARC Audit and Alignment Cycle" by Interlock IT

1. Discovery: Map every sending subdomain and mail source—internal and external.

2. Authentication Review: Confirm SPF/DKIM for each, fixing misalignments promptly.

3. Policy Modeling: Choose your DMARC enforcement and subdomain policy path based on current risk and operational readiness.

4. Reporting: Enable and regularly analyze DMARC aggregate and forensic feedback for every domain and subdomain.

5. Iterative Action: As new mail sources or business lines launch, return to Step 1—DMARC policies must evolve with your company's growth.

FAQ: DMARC Subdomain Policy

Q: Does DMARC always protect subdomains by default?

A: Yes, unless a subdomain publishes its own DMARC record, it will inherit the parent domain’s policy. The sp tag allows customizing enforcement for subdomains without separate records.

Q: When should I give a subdomain its own DMARC record?

A: When a subdomain needs a different policy (for example, separate reporting, operational separation, or a unique risk profile). Most subdomains don’t need separate records unless managed by another team or vendor.

Q: What happens if I forget to audit all subdomains before enforcing DMARC?

A: Legitimate email can be blocked or sent to spam. This is especially risky if legacy apps or marketing platforms are in use. Always audit first, enforce later.

Q: How do I know which subdomains are sending mail?

A: Start by reviewing DMARC aggregate reports. Consider a full audit, working with experts like Interlock IT who specialize in cloud, Google Workspace, and Microsoft 365 ecosystems.

Q: Can attackers exploit unprotected subdomains?

A: Yes. Attackers target less-monitored subdomains to spoof brands or phish customers. Proactive, continuous DMARC review of all mail-sending subdomains is critical.

Q: Do I need to set up SPF and DKIM separately for subdomains?

A: Yes, each subdomain that sends mail must have working SPF/DKIM aligned to its mail sources, or inherit valid records from the parent, depending on DNS setup.

Conclusion

DMARC is not just a checkbox, and proper subdomain enforcement is often what separates truly secure organizations from those that fall victim to phishing or business email compromise. By auditing every sender, aligning all sources (including subdomains), and reviewing reports vigilantly, you turn DMARC into a living security control for your growth journey.

If you want an expert audit or help with Google Workspace, Microsoft 365, or mapping your full email attack surface, Interlock IT is Ontario’s trusted cloud partner for DMARC audits and cloud solution integration. Reach out for guidance and make sure your entire domain—top to bottom—is protected for the future.

Google Groups vs Hiver: Which Shared Inbox Fits a Growing Support Team?

Choosing the right shared inbox solution is a critical decision for any growing support team. The choice between Google Groups (Collaborative Inbox) and Hiver can shape how your team handles customer requests, coordinates workload, and tracks accountability as volume scales. While Google Groups is often the first stop for businesses using Google Workspace, it is important to recognize where its simplicity can become a limiting factor, especially as teams grow and demands for efficiency, ownership, and reporting intensify.

Based on deep experience working with Canadian small and mid-sized businesses, Interlock IT recommends a close look at your daily support volume, collaboration needs, and process maturity before deciding. For businesses just starting out or handling minimal support requests, Google Groups offers an accessible entry point. However, once the need for workflow automation, analytics, and robust team coordination becomes prominent, Hiver consistently proves to be the optimal solution for scaling operational excellence within Gmail.

Definitions: What Are Google Groups and Hiver?

Google Groups Collaborative Inbox is a tool included with Google Workspace that allows teams to create shared mailboxes (like support@ or info@). It lets multiple users access, assign, and respond to emails from a central location, working well for teams that can manage conversations manually with basic organizational controls.

Hiver is an advanced shared inbox and helpdesk platform that integrates directly within Gmail. It adds workflow features such as ticket assignment, conversation status, collision detection, internal notes, automation, and analytics. For organizations using Google Workspace, it layers structured support operations on an otherwise familiar Gmail experience.

Direct Comparison: Google Groups vs Hiver for Growing Support Teams

The essential question is not which tool is cheaper, but which solution supports smooth scaling, customer satisfaction, and internal accountability as your team and ticket volume increase. Here’s how each option stacks up:

Google Groups Collaborative Inbox

• Included for free with Google Workspace

• Basic shared inbox controls: assign, label, and mark conversations as resolved

• Setup requires minimal time and technical expertise

• Suitable for very small teams (typically 1-5 users) managing low daily email volumes

• Limited tracking or workflow features

Key Limitations of Google Groups for Support Teams

• No real-time collision detection — risk of duplicate or conflicting replies

• No built-in internal notes for staff-only discussions or context on tickets

• Lacks SLA tracking and automated workflow orchestration

• Reporting is manual and basic, often requiring exports to external tools

• Minimal automation or advanced routing

These constraints mean that Google Groups can be viable for basic needs, but quickly becomes inefficient as email traffic rises or support processes mature. Many businesses reach a tipping point where manual inbox management leads to missed messages, lack of accountability, or difficulty measuring team performance.

Hiver: Features for Modern Support Operations

• Native integration inside Gmail keeps adoption high

• Advanced assignment: conversations can be manually or automatically routed to specific owners

• Collision detection to prevent double replies

• Internal team notes invisible to external recipients

• Status tracking for open, pending, and closed issues

• Robust automation for tagging, routing, and escalation

• Built-in analytics for response times, workload, and SLA measurement

By delivering these workflow controls within Gmail, Hiver supports both operational efficiency and user adoption, minimizing the learning curve for staff transitioning from traditional group email practices.

Side-by-side Comparison Table

Feature	Google Groups (Collaborative Inbox)	Hiver
Cost	Included with Google Workspace	Paid, with free trial and paid tiers (commonly start at $25/user/month)
Best For	Very small teams and low volume	Growing support teams that need structure and accountability
Works Inside Gmail	No native workflow	Yes, in Gmail interface
Assignment	Basic manual assignment	Manual and automated assignment
Collision Detection	No	Yes
Internal Notes	Limited	Full support
SLA Tracking	No	Yes
Reporting & Analytics	Manual/limited	Robust dashboards and analytics
Automation	Basic (filters only)	Workflow rules, routing, escalation
Scalability	Sufficient for low complexity needs	Designed for scaling support teams

When to Choose Google Groups (Collaborative Inbox)

• Your support team is only 1 to 5 people

• Email volumes are low and manageable without automation

• No requirement for SLA tracking, advanced reporting, or clear ownership

• Cost minimization is the top priority

In these cases, Google Groups offers a familiar, low-maintenance way to start managing group email traffic, especially if the risk of missed messages or double-handling is low.

When to Upgrade to Hiver

• Your team frequently misses messages or replies to customers more than once

• Support requests must be tracked, assigned, and escalated

• Managers need reports on team workload or response times

• You cannot afford to rebuild your support workflow every time the team grows

For many organizations, Hiver’s value emerges once support volume exceeds about 50 emails per day, team size increases, or expectations for consistent service become part of daily operations.

Step-by-step: Assessing Your Inbox Needs

1. Track average daily inbound messages over a two-week period

2. Identify every team member involved with the shared address

3. Record instances of duplicate replies or missed responses

4. Determine if managers require workflow visibility, analytics, or accountability tracking

5. If advanced workflow is needed, consider a solution like Hiver rather than stretching Google Groups past its intended use

Best Practices for Implementing a Shared Inbox Solution

• Start by documenting your support workflow and identifying bottlenecks (assignment, follow-up, analytics)

• Select tools that integrate naturally with your team’s primary interface (such as Gmail for Google Workspace users)

• Plan for change management and ensure all staff are trained on new features (a key service from Interlock IT)

• Automate where practical, but avoid overcomplicating the process for your current team size

• Regularly review analytics to continually refine your support process

How Interlock IT Helps Canadian Businesses Make the Right Choice

At Interlock IT, our team brings years of hands-on experience guiding organizations through the evolving needs of group email management. We support the complete lifecycle from initial license acquisition (Google Workspace, Microsoft 365), to inbox strategy, to hands-on migrations and ongoing optimization. As a certified Hiver partner, we help businesses implement best practices for shared inbox workflows and realize the full potential of their support team inside Gmail.

Our services also include DMARC auditing and cloud backup, all geared toward streamlining productivity and ensuring the reliability and security of your critical communication systems.

Frequently Asked Questions

What is the key difference between Google Groups and Hiver?

Google Groups provides basic shared inbox features suitable for small teams, while Hiver brings advanced workflow tools such as ticket assignment, collision detection, automation, and analytics inside Gmail, which supports bigger teams and higher operational demands.

When should a business move from Google Groups to Hiver?

Consider upgrading when support volumes rise, team sizes grow beyond five users, accountability or performance tracking is needed, or if missed messages and duplicate replies become routine issues.

Is Hiver only for customer support teams?

While Hiver is especially popular with customer support, many businesses leverage it for shared sales, admin, and billing inboxes—anywhere structured, collaborative inbox management is needed.

Does Hiver require migrating away from Gmail?

No, Hiver operates directly inside Gmail, so users maintain their existing workflow, improving adoption and reducing training needs.

Can Interlock IT help configure both Google Groups and Hiver?

Yes. We assist clients with strategic advice, configuration, onboarding, migrations, and ongoing change management for both solutions depending on business need.

Conclusion: Making the Smart Choice for a Growing Support Team

Ultimately, Google Groups remains a solid starting point for basic shared inbox requirements, while Hiver delivers the workflow automation, structure, and visibility needed by expanding teams. Any Canadian business working toward more efficient customer support or internal collaboration should reevaluate its shared inbox solution as needs evolve. For expert, unbiased advice and hands-on implementation, trust the leaders at Interlock IT to future-proof your team’s support workflow.

If you're ready to improve shared inbox management, compare solutions with our team or schedule a consultation to review your Google Workspace license and DMARC audit options.