Health Check, Security Center, manual audit, OrgGuardian: what each one sees, and what none of them sees

What does each of the four see?

Each row is a plane of observation, not a feature, and each cell takes only three values. yes: the plane is covered. partial: one facet only, and the caveat is spelled out in black and white in that tool's section below. no: no coverage described for this plane — which states what we found, not what the tool would be incapable of.

Two readings jump out, and they cut both ways. The manual audit column is almost full: a competent human, given enough time, has virtually no blind spot of capability. And the last row is the only one where OrgGuardian says no when Security Center says yes — that is deliberate, and it is explained below.

Health Check: the only source on settings

The native Health Check scores session and password settings against a baseline, across four risk levels, and accepts custom baselines if your internal standard differs from Salesforce's. It is included, it does not have to be installed, and it reads in a minute. Health Check (Salesforce Help).

It does not only read. Its “Fix Risks” button updates several security settings — or all of them — in a single action, against the chosen baseline. That is why it earns a partial on the “deploying a security policy” row, and the caveat fits in one sentence: it applies a baseline inside one org, where Security Center pushes a policy to a fleet. Configure Health Check (Salesforce workshop).

On that particular plane, it reads what OrgGuardian does not read. Minimum password length, expiry, session timeout, locking sessions to the IP address, forced re-authentication, clickjack protection, login IP ranges, login hours: these settings are not exposed to a SOQL query. They can only be read through the Metadata API, which OrgGuardian has chosen not to do by default. Ten checks are explicitly deferred in its code for that reason — password length and expiry, session timeout, IP session locking, re-authentication, HttpOnly, clickjack protection, SMS identity confirmation, login IP ranges and login hours. An optional gate (Org_Hardening_Audit) switches them to a real configuration read; they stay deferred while it is closed, and it is closed by default.

Its limit is one of scope, not of quality: it looks at neither effective permissions, nor connected apps, nor outbound integrations, nor code. A Health Check score of 90% is compatible with an integration account that combines Modify All Data and an API with no MFA. It is also point-in-time: a score states the state at the moment someone clicked.

The two reservations behind a “partial” rather than a “no” — found while sourcing this table on 2026-09-08, and correcting two false claims it used to make. Guest access: since Winter ’24, Health Check exposes two settings named Number of Objects to which Guest User Profiles have Read Access and … Edit Access. It counts exposed objects; it names neither the site, nor the profile, nor the record — hence partial. Organization-wide defaults (OWD): Health Check does carry a check, Number of Objects with Default External Access Set to Public, rated high risk. Again it is a count of objects, not the sharing matrix: neither the role hierarchy, nor sharing rules, nor manual sharing. Verified outside the documentation, by a read-only Tooling API query on our own org: SELECT RiskType, SettingGroup, Setting FROM SecurityHealthCheckRisks.

Security Center: the fleet, and the policy you push

Security Center aggregates the security of several orgs into a single view: child orgs report their data up to a parent org. That is its reason for existing, and on that ground it is more direct than OrgGuardian. It exposes more than eighty security and governance metrics — authentication methods, permission assignments, installed packages, Health Check data — with customisable notifications when one of them moves. Security Center (Salesforce Help).

Two capabilities deserve to be named without being played down. The first: it shows when a user gains or loses a permission, and through which profile or which permission set they obtained it. The second: it deploys a policy — session timeouts, trusted IP ranges, password settings, Health Check baseline — to the orgs concerned.

That second capability is the one OrgGuardian will not have. Security Center acts; OrgGuardian observes and documents. If what you need is to enforce a configuration standard across a fleet of orgs, Salesforce's tool is the one that does it, and no comparison page will change that.

What we did not find described in its public documentation: monitoring of outbound integrations and callout endpoints, analysis of the deployed Apex code, article-by-article mapping to DORA or NIS2, risk priced in euros, and remaining headroom on platform limits — its documented metrics cover authentication, permission assignments, installed packages and Health Check data, not limit consumption. That is why this row earns a no, in the sense this table gives the word: no coverage described, not an incapacity. It is a licensed product, and we do not comment on its price.

Four reservations, found while sourcing this table on 2026-09-08 — three of them correct a “yes” this table should never have written. Effective permissions: the documentation describes consolidating critical system permissions (View All Data, Modify All Data), not resolving profile + combined permission sets for a given user. Integration accounts without MFA: both facets exist separately — an Authentication by Type card, and tracking of users without MFA — but nothing documents crossing them on integration accounts. Connected apps: the inventory is documented (which apps, installed by whom, when), not OAuth scopes nor dormant tokens. Certificates: the TenantSecurityCertificate object carries ExpirationDate and KeySize — two of this plane’s three attributes. Enumerating the TenantSecurity* family, however, returns no Named Credential, External Credential, Remote Site Setting or callout endpoint object: outbound integrations themselves remain undescribed.

The manual audit: the only one of the four with judgement

A human auditor is the only one who can ask why a permission exists. They call the person who granted it, they learn that the account serves a quarterly billing flow, and they decide. No tool does that. They are also the only one who sees what lives outside the org: the middleware, the data warehouse, the workstation where the export landed.

Their blind spot is therefore not coverage, it is the calendar. The effective permission of an account is the sum of its profile and of every permission set assigned to it, and that sum changes between two reviews. On an org of a few hundred users, a serious review is counted in days — and it is out of date the next day. The cartesian product profiles × permission sets × users exceeds what a quarterly review can cover.

This is why the right question is never “tool or human”: the first pass is done perfectly well by hand, it is the repetition that calls for tooling.

OrgGuardian: the planes it measures, and those it does not

OrgGuardian installs into the org and measures what is queryable from Apex. Concretely, and this is verifiable in its code: the effective permission of every active user, computed as the union of their profile and of every permission set assigned, with escalation detection between two scans; the accounts — human and integration alike — not covered by a permission enforcing MFA; connected apps with their scopes, their usage volume and the date their tokens were last used; the object permissions actually carried by each Experience Cloud guest profile; the sharing defaults that expose records for read or for write, internally as well as externally; named credentials and CSP trusted sites; the headroom on platform limits; risky administrative actions over the last seven days; configuration drift by fingerprint between two measurements; and the security postures of every first-party Apex source — classes and triggers alike — with a debt score derived from them.

Everything above is read by a plain query, without a single outbound call. That is what runs in a standard scan, with no configuration, from installation onwards.

What it does not do — the complete list

1. It never remediates. This is a design posture, not an incomplete version 1. A remediation takes the form of a business-impact statement, a risk level for the change, numbered steps and a link to the right Setup screen. The action stays human, end to end.
2. It does not read session and password settings. Ten checks — password length and expiry, session timeout, locking to IP, re-authentication, HttpOnly, clickjacking, IP ranges, login hours — are deferred in the code because they are not exposed to SOQL. That is exactly Health Check's territory, and it is the simplest reason to keep both.
3. It does not see what leaves the org. It sees the declared endpoint and the OAuth scope granted. It does not see the system on the other side, nor what that system does with the data once the data has arrived there.
4. A large part of the outbound inventory is switched off on delivery. Remote Site Settings, External Services, outbound messages, external credentials, certificate expiry dates, endpoint probing: none of these objects is exposed to a query. They require the Tooling API, which is to say an outbound call to your own org. These detectors exist, they sit behind switches, and those switches are off by default so that a standard installation produces no outbound traffic. Turning them on is an administrator's decision, not a factory setting.
5. The Apex code analysis is a pattern detector, not a static analyser. It reads every first-party class and trigger, spots the security postures missing from the deployed code and measures debt. It does not prove the absence of a logic flaw: it recognises shapes, it does not follow a value through a call graph. That is a limit of depth, not of scope — a human reading the same code sees things it will not.
6. Regulatory mapping is not a guarantee of compliance. 95 mappings out of 118, across all frameworks taken together, are declared partial: they observe only the facet named by their evidence. The scope of each mapping is displayed in the product.
7. Multi-org aggregation is an option, not the default mode. It is reserved for the top tier, disabled at installation, and requires one cross-org named credential per linked org. Security Center starts there; OrgGuardian gets there.
8. The finding texts are written in French. Business impact, remediation steps, summaries: there is not yet an English variant of these texts in the package.

And Shield? What it encrypts, what it logs

Shield is not a fifth competitor, and that is why it is missing from most comparisons: it does not answer the same question. The four tools above say what state the configuration is in. Shield — three products sold together — acts on the data itself: Platform Encryption encrypts it at rest, Event Monitoring logs who did what (logins, report exports, API calls, queries), and Field Audit Trail keeps field history for up to ten years. None of the three says that an integration profile combines Modify All Data and an API without MFA; none of the other four says who exported a report last night.

The question actually being asked — “we have been quoted Shield, do we need both?” — has a short answer: they do not replace each other, and one enriches the other. Without Event Monitoring, OrgGuardian infers bulk export from a capability (the right to do it); with it, it observes it (who did it, when, from where), and its log detectors — abnormal logins, slow queries, unhandled errors — switch on. It is an option disabled at install, reserved to the Enterprise tier, and it creates no outbound flow: the log files are read from the org, inside the org.

What settles the budget question is the risk you carry. An obligation to encrypt at rest or to retain history (DORA art. 9, sector rules) is met with Shield, and with nothing else. An over-privileged integration profile, a dormant OAuth token, a guest site exposing an object are met with a configuration measurement — and Shield, whatever its price, will never see them. Salesforce does not publish Shield's price; we will not make it a table column.

What does none of the four see?

The honest part of a comparison is the part where all four columns are empty.

• Intent. A permission legitimately used and the same permission misused have exactly the same signature in the configuration. None of the four tells them apart.
• The data once it has left. An export may leave an administrative trace. What happens to the file afterwards — where it is dropped, who reopens it, how long it stays — no longer belongs to the org, and escapes all four.
• The other side of the integration. The org knows that it calls an endpoint. It does not know who operates it, nor whether that system is itself kept in order.
• The business criticality of a field. That a column carries contractually sensitive data is a piece of information that has to be declared. It cannot be deduced from any metadata.
• Compliance itself. All four produce facts. The compliance verdict remains a judgement, made by a person who puts their own responsibility on the line.

How do you choose? One sentence per case

If you want to know where you stand on settings: Health Check, tonight, with nothing to install and nothing to buy. If you run a fleet of orgs and want to enforce a common standard across it: Security Center. If you have to understand one particular situation, with context and with people to question: a manual audit, and nothing else. If the problem is that the measurement does not repeat often enough, that it reaches neither effective permissions nor integrations nor code, and that it has to be presented to an auditor: that is OrgGuardian's ground.

Should you uninstall Health Check if you install OrgGuardian?

The question does not arise — Health Check is native, it is neither installed nor uninstalled. And it would be a bad idea to stop reading it: it covers the ten settings checks that OrgGuardian has explicitly deferred.

Do Security Center and OrgGuardian overlap?

On permissions, connected apps and drift, yes, in part. Not on outbound integrations, code, regulatory mapping or pricing the risk. And not at all on the nature of the tool: one deploys a policy, the other stays read-only.