How to Deduplicate SaaS Inventory Without Merging Risks

Oct 7

6 min read

To deduplicate a SaaS inventory safely, normalize vendor and product names while preserving tenant, account and authorization records. Use domains and aliases as matching clues, not automatic proof that two findings describe the same service instance. Record each merge decision, retain source evidence, and test whether the resulting inventory still exposes every distinct identity and access path.

In brief

Decide whether you are counting vendors, products, tenants or accounts before merging records.
A shared domain or similar name is a candidate match, not a final identity.
Group related products for reporting without collapsing their access boundaries.
Make merges reversible and verify that evidence and grants survive.

An inventory containing “Paper Harbor,” “PaperHarbor EU” and “Paper Harbor AI” looks untidy. An analyst merges them into one record. The application count falls and the dashboard becomes cleaner.

Then an offboarding reviewer cannot tell whether an employee had access to the corporate workspace or a separately created personal team. The tidy inventory has lost information the security process needs. Deduplication succeeded cosmetically and failed operationally.

The names in this example are hypothetical. The lesson is a practical one: deduplicate labels and duplicated observations, not distinct risk relationships.

Step 1: define the unit you are deduplicating

Write a short inventory rule before changing records. For example: one product record can have multiple tenant records, and each tenant can have multiple identities and integration grants. A vendor can own several products without those products becoming interchangeable.

The NIST Cybersecurity Framework 2.0 includes software and supplier-service inventories. It does not prescribe the entity model below. This model is a recommended way to preserve the distinctions needed for access and governance reviews.

Entity	Question it answers	Safe grouping approach
Vendor	Which supplier provides the service?	Group verified product ownership under one supplier.
Product	Which application or capability is involved?	Normalize confirmed aliases for that product.
Tenant or workspace	Which service instance contains the relationship?	Keep distinct instances under their product parent.
Account or identity	Who or what has the relationship?	Reconcile identifiers within the relevant instance.
Grant or credential relationship	Which authorization path exists?	Retain scope, subject and target context.

This hierarchy supports two useful views: a compact supplier summary for leadership and a detailed access view for analysts. Neither requires deleting the distinctions the other depends on.

Step 2: normalize domains without assuming ownership

Store the observed hostname and your normalized representation separately. Remove incidental URL components when comparing hostnames, handle internationalized domain names consistently, and retain the transformation rule used.

Do not calculate a registrable domain by always taking the last two labels. Public suffixes vary. The Public Suffix List provides a maintained reference for suffix boundaries. Choose and document how your parser handles its rules, including private suffix entries where relevant.

A suffix-aware domain result is still not an authoritative vendor identity. Hosted services, custom domains and separate products can complicate the relationship. Use it to generate a review candidate, then corroborate ownership and product mapping with official documentation or trusted internal records.

A useful normalization record contains the original host, normalized host, registrable-domain result, parser version and confirmed product mapping. Do not discard the original merely because the normalized version is easier to search.

Step 3: build an alias map with evidence

Create an alias record when there is a reason to believe two labels refer to the same product. Record that reason: a documented rebrand, an official product page or an administrator-confirmed tenant label. Add an effective date when a rename could change historical interpretation.

Fuzzy name matching is useful for finding candidates. It is a poor final authority. Similar names can describe different services, and a company acquisition can connect suppliers without combining their products or contracts.

For the hypothetical Paper Harbor example, a regional label might be an alias for the same product. “Paper Harbor AI” might instead identify a separately licensed feature with different controls. Verify those relationships before setting a shared approval status.

Step 4: protect tenant and identity boundaries

The OWASP Multi Tenant Security Cheat Sheet emphasizes tenant context and isolation in application design. For inventory governance, the related practical lesson is to preserve tenant context in records rather than assume one vendor means one security boundary.

Before a merge, check whether the findings refer to the same organization-controlled workspace. An employee's account in an independently created team should not automatically inherit the corporate tenant's SSO coverage, AI settings or administrative ownership.

Keep account identifiers scoped to the application instance. Reused email addresses, contractors and shared mailboxes can complicate person matching. If the tenant is unknown, retain that uncertainty rather than manufacture a common tenant to complete the merge.

Step 5: keep authorization records intact

An application name is not enough to identify an authorization relationship. Microsoft's permissions and consent overview distinguishes delegated access from app-only access. An inventory merge should not flatten those different subjects and access models into one user-level flag.

Retain the application identifier, relevant tenant, permission type, resource and observed scopes or roles. Grouping two display names must not erase a separate grant, make a tenant-wide permission look user-specific or hide an unresolved integration.

Count relationships before and after the change. If your merge logic reduces the number of identity or grant records, require an explicit explanation for every reduction. A smaller product count does not justify losing access evidence.

Step 6: verify the merge with a small acceptance checklist

Candidate evidence: can a reviewer explain why the names belong together?
Product scope: are distinct applications or AI features still distinguishable?
Tenant scope: can the reviewer identify each known workspace?
Identity retention: did every account relationship survive or receive a documented reconciliation?
Authorization retention: did scopes, permission types and source references survive?
History: can the record show what was observed before the merge?
Rollback: can the team reverse the decision if later evidence contradicts it?

These checks also make automation safer. Automate well-supported alias transformations; send ambiguous ownership or tenant matches to review. A pending match is preferable to an irreversible incorrect merge.

How discovery supports a cleaner inventory

Waldo Security's SaaS discovery helps surface applications and identity relationships outside traditional inventories. Use that context to review duplicates and unresolved mappings. This guide recommends an inventory process; it does not claim that every normalization or rollback feature described is built into Waldo.

The unified Waldo platform connects SaaS, AI, identity, OAuth and cloud context. A deduplicated reporting view should preserve those relationships so an application owner can make a specific governance decision instead of inheriting a vendor-wide assumption.

Key takeaways

Normalize confirmed aliases while retaining original evidence.
Use domain parsing to support matching, not establish ownership by itself.
Keep tenants, accounts and permissions separate from supplier summaries.
Measure merge quality by retained context and reviewability, not just fewer rows.

Frequently asked questions

Should two applications from the same vendor be merged?

Only at the supplier-summary level unless evidence shows they are the same product. Different applications may have different accounts, terms, AI features and controls.

Can a registrable domain be used as a unique application key?

It can help identify candidates, but it is insufficient as a universal key. Preserve product and instance identifiers where available.

How should regional domains be handled?

Confirm whether they represent the same product, separate instances or different service terms. Normalize the vendor relationship without erasing relevant regional or tenant distinctions.

Is fuzzy matching safe to automate?

It is suitable for candidate generation. Automatically merging ambiguous matches can lose ownership and access context; require corroborating evidence for the final decision.

What happens to historical findings after a rebrand?

Keep the observed historical name and link it to the current product record using a documented alias relationship. This preserves searchability and the original evidence.

Which metric shows whether deduplication worked?

Check confirmed duplicate reductions alongside retained tenant, identity and grant relationships. Review incorrect merges and unresolved matches. Application-count reduction alone is not a quality measure.

Review the inventory behind the dashboard

Use a Waldo Security free trial to assess discovered application and identity context. A cleaner inventory should make risk easier to investigate, not remove the details needed to govern it.

Sources and further reading

NIST: The NIST Cybersecurity Framework (CSF) 2.0. February 26, 2024.
Public Suffix List project: View the Public Suffix List. Continuously maintained; accessed October 2, 2026.
OWASP: Multi Tenant Security Cheat Sheet. Rolling guidance; accessed October 2, 2026.
Microsoft: Overview of permissions and consent in the Microsoft identity platform. Rolling documentation; accessed October 2, 2026.