Compare operating obligations rather than deployment labels
Self-hosted and SaaS describe delivery models, not complete security or reliability outcomes. A self-hosted authentication platform may give an organization more control over infrastructure while adding maintenance obligations. A SaaS service may move parts of that maintenance to a supplier while leaving customer configuration, access and data decisions with the organization. The useful comparison is an evidence-based responsibility matrix for the actual service, not a claim that one label is always safer.
Microsoft's shared-responsibility guidance illustrates how responsibilities change across on-premises, IaaS, PaaS and SaaS models. It also identifies responsibilities customers retain. This source describes Microsoft's cloud framework; it is not a contractual allocation for EmailAuth or proof that EmailAuth offers a self-hosted product. This manuscript proposes a comparison method without deploying software or accessing infrastructure.
Define what is actually included in each option
Record the supported product edition, deployment model, environment boundary, infrastructure provider and supplier assistance described in current documentation or an approved offer. “Self-hosted” might mean software operated on owned hardware or on cloud infrastructure; those arrangements can allocate physical, operating-system and application responsibilities differently. “Private” might refer to network connectivity, dedicated resources or a contractual arrangement. None of these terms should substitute for a concrete architecture and support boundary.
Ask which components exist and who operates them: application runtime, data stores, queues, report ingestion, authentication, backups, monitoring and administrative interfaces. Treat this list as questions, not an assertion that the platform uses those components. If the supplier cannot provide evidence for a claimed deployment option, mark the option unverified rather than filling in an architecture from a different product's documentation.
Assign maintenance and change ownership
For each supported component, identify who patches it, who approves changes, who schedules maintenance and who verifies recovery. A supplier may publish updates while the customer must install them. A managed service may apply updates while the customer must assess changes to integrations or access policy. Responsibility for distributing a fix is not the same as responsibility for confirming that the customer's actual workflow still operates afterward.
Microsoft's framework distinguishes underlying cloud infrastructure from customer data, identities and configuration. Apply that distinction to the comparison without copying its matrix as a universal contract. The actual supplier should state its responsibilities and exclusions. The customer should identify a named internal owner for retained obligations rather than assigning them vaguely to “IT.” Unowned responsibilities are a gap even when the deployment model is otherwise suitable.
Map external dependencies explicitly
An authentication operation may depend on DNS hosting, sending providers, identity systems, report sources and external monitoring. Moving the platform does not automatically move control of those dependencies. A self-hosted application cannot alter a supplier's sending behavior without the relevant authority, and a SaaS dashboard cannot guarantee that every receiver supplies reports. Record the dependency owner, supported interface, failure mode and evidence used to verify its state.
RFC 9990 defines DMARC aggregate reporting as a distinct reporting process. Its availability and coverage should not be inferred solely from the platform's uptime. RFC 9989 defines domain authentication relationships, which also depend on the actual sending configuration. The operating matrix should separate platform availability from completeness of observations and correctness of sender authentication.
Evaluate access and tenant responsibilities
Azure's multitenant identity guidance distinguishes identity, authorization and entitlements. A deployment comparison should ask who configures identity-provider trust, user roles, service identities, tenant bindings and export permissions. A dedicated deployment does not automatically mean every user inside it should access all data. A shared service does not automatically imply that customer data is exposed across tenants.
Require actual evidence of the supported controls and administrative boundaries. Record supplier support access, emergency access and audit responsibilities where applicable. Do not assume that customer ownership of the infrastructure eliminates supplier access or that SaaS ownership eliminates the customer's role in offboarding users. No permissions, accounts or security settings were changed for this article; these are questions for authorized review.
Compare recovery evidence and operational capacity
Ask what backup, restore and disaster-recovery obligations each option assigns, which components are covered and what evidence demonstrates recovery. A backup configuration is not a successful restore test. A supplier availability statement is not proof that an individual customer's data and integrations can be recovered within the buyer's requirements. Record the actual supported commitments and the customer's remaining verification work without inventing recovery times.
Estimate workload only from approved organizational inputs. Include operating-system or runtime maintenance where retained, application upgrades, incident response, access review, integration support and recovery exercises. Do not assume self-hosting is cheaper because subscription charges differ, or SaaS is cheaper because infrastructure work is less visible. This draft calculates no staffing requirement, total cost or savings. It supplies categories for a transparent comparison.
An operating-responsibility worksheet
Create one row per obligation with component, dependency, customer owner, supplier owner, execution party, approval party, evidence reference, review trigger and unresolved gap. Distinguish responsibility for performing a task from accountability for its outcome. Add the supported deployment version and contract reference so the allocation can be reviewed when either changes. Keep credentials and sensitive architectural details out of broadly shared copies.
The decision section should identify unacceptable gaps, approved compensating controls and dependencies that require further evidence. A row marked shared should name the handoff: what each party does, what signal triggers the next step and who verifies completion. “Shared” without a defined handoff can conceal the most important failure boundary. This proposed worksheet has not been populated with a real supplier agreement or operating environment.
Fictional diagnosis: updates without an installation owner
A fictional team compares a managed service with a self-hosted option. The self-hosted supplier promises to provide security updates, and the buyer initially treats patching as supplier-owned. The detailed review reveals that the supplier distributes packages while the customer must schedule installation, assess compatibility and verify the resulting service. No internal team has accepted that work.
The proposed response is to assign an authorized owner and assess capacity before selecting the option, or to choose a supported arrangement with a different responsibility allocation. The team should not declare the product unsafe merely because the obligation exists. This scenario is fictional and does not describe EmailAuth's offerings, an actual missed patch or a deployment performed during this work.
Make the decision with the gaps visible
A defensible comparison explains which obligations move, which remain and which dependencies are unchanged. It does not treat control as proof of competence or outsourcing as proof of complete coverage. The preferred model depends on supported product options, organizational capacity, required controls and verified supplier commitments.
The catalogue requires an evidence-based operating-responsibility and dependency matrix. That original artifact remains open. Human specialist review, source applicability, production routes, accessibility and owner release also remain open. This draft supplies a framework and fictional exercise, not an implemented architecture or an approved responsibility agreement. Publication requires current evidence for the actual options being compared and clearly assigned ownership for the retained work.