Software Supply Chain Security for Real Estate and Proptech: 90-Day Plan

Software supply chain security for a property manager, a real estate investment trust (REIT), a brokerage, a title or mortgage company or a proptech vendor comes down to three jobs: know every component inside the software you build (tenant portals, rent payment flows, listing sites, mobile apps and building integrations), know which vendor runs every system you buy (property management, accounting, title and escrow, loan origination, access control and building automation), and put both on a patch clock that someone owns and can prove to a regulator, an investor or a customer's security review. In this industry most of the money moves through software someone else wrote, so the program is half procurement and half engineering. A focused team can stand up the inventory, the gates and the vendor evidence in about 90 days.

This guide covers the software the industry runs, the US rules that apply, public incidents from the last three years, the people who own each part, and a 30, 60 and 90 day plan that works with whatever tools you have. Safeguard appears only near the end. Nothing here is legal, regulatory or audit advice; your counsel, your auditors and your regulators decide what applies to you.

Key takeaways

• Real estate runs on a long chain of bought software: property management systems, tenant screening, rent payments, listing feeds, title and escrow platforms, loan origination, and in commercial buildings, access control and building automation. Proptech vendors build much of it on open source.
• The FTC Safeguards Rule (16 CFR Part 314) is the rule most of the transaction side meets first. It covers non-bank financial institutions such as mortgage brokers and lenders, requires secure development practices for in-house apps, oversight of service providers, and since 13 May 2024, a notice to the FTC within 30 days of a breach affecting 500 or more consumers.
• Mortgage companies approved by FHA must tell HUD about significant cybersecurity incidents within 12 hours of detection, under Mortgagee Letter 2024-10. Licensed title insurers and mortgage firms in New York answer to 23 NYCRR Part 500.
• Four of the largest US title and mortgage businesses disclosed cyber incidents between October 2023 and January 2024, and the filings describe disruption that reached agents, lenders and borrowers who depend on those platforms.
• Six roles own the problem: the CISO, the VP of Engineering at a proptech or digital team, the GRC or compliance lead, the procurement or vendor risk owner, building technology and facilities IT, and the startup CTO who also owns compliance. Each has a different deadline.
• Safeguard capabilities covered in this post, all GA: SBOM generation and analysis, software composition analysis (SCA), vulnerability management with EPSS and KEV, reachability analysis and prioritization, policies, gates and guardrails, autonomous remediation (ships switched off), SAST, DAST, license compliance, Third-Party Risk Manager (TPRM), the Compliance and GRC suite, Trust Center, Portal audit trails, the local runner and CLI, and on-prem, air-gapped and Zero AI deployment options.

What software real estate and proptech run

Supply chain risk starts with a map. Real estate is several industries sharing one asset class, and each corner runs different software that touches money, identity documents or physical access.

Property operations. The property management system (PMS) holds leases, units, tenants, work orders and the general ledger for each property. Around it sit tenant screening (credit, background and eviction history pulled from consumer reporting agencies), online leasing and e-signature, resident portals and apps, maintenance and work order tools, utility billing, and accounting integrations that roll property ledgers up to the owner or fund.

Payments. Rent, deposits and fees move through online payment portals, card acceptance, ACH debits and, increasingly, embedded payment features inside the PMS. Owner distributions and vendor payables move the other way. A payment page served from a resident portal loads scripts in the tenant's browser, just like any checkout.

Brokerage and listings. Brokerages run agent CRMs, transaction management and document workflow, listing syndication, and websites fed by Multiple Listing Service (MLS) data through standard web APIs. Agents add a long tail of browser extensions, marketing tools and showing apps.

The transaction: title, escrow and mortgage. Title companies run title production and escrow accounting, which produce the wire instructions for a closing. Lenders and brokers run loan origination systems with integrations to credit bureaus, income and employment verification, appraisal management and disclosure delivery. Servicers run loan servicing platforms that hold borrower data for decades.

Commercial buildings. Office, retail, industrial and multifamily buildings run building automation systems (HVAC, lighting and energy controls), physical access control with badge readers and door controllers, video surveillance, elevator management, visitor management, smart locks and package rooms, plus tenant experience apps. Much of this is operational technology installed and maintained by integrators, and it often reaches the same network as corporate IT.

Proptech platforms. The vendors behind all of the above are software companies. A proptech company ships a multi-tenant web app, mobile apps, a public API, integrations with dozens of partners, and the open source dependencies under each one. Its customers' supply chain risk is its own product security program.

Why the supply chain is so wide here

1. Owners, operators and managers are different companies. A building can be owned by a fund, managed by a third-party property manager and leased to tenants who install their own systems. Contracts do not always say who patches the access control server.
2. The transaction crosses many firms in a few weeks. A single home sale touches a brokerage, an MLS, a lender, a title agent, an underwriter, an appraiser and several software vendors. A weak link anywhere can end in a changed wire instruction.
3. Small teams with large data. Many property managers and title agencies have a handful of IT staff and rely on vendors and managed service providers, while holding tenant screening reports, bank details and identity documents for thousands of people.
4. Long-lived building systems. Building controllers and access panels stay in service for many years, and their firmware and management software age with them.

The table below is a starting map. Give every row an owner before you start the plan.

The regulations and frameworks that apply

There is no single real estate cybersecurity law in the US. The rules arrive through the money (lending, title insurance, payments), through public markets, and through state privacy law. Check which of the rules below reach your business with counsel; the list is a starting point, not a scoping opinion.

The FTC Safeguards Rule (16 CFR Part 314)

The Gramm-Leach-Bliley Act Safeguards Rule, enforced by the FTC, applies to financial institutions under FTC jurisdiction that are not banks. In real estate that typically means mortgage brokers, non-bank lenders and servicers, and other firms that provide financial products or services to consumers; the rule's own definition section lists examples, and your counsel should confirm whether yours is one.

The 2021 amendments made the rule specific. Section 314.4 requires a written information security program run by a "qualified individual", based on a written risk assessment. Several elements map straight onto the software supply chain:

The FTC amended the rule again in October 2023. Since 13 May 2024, a covered firm must notify the FTC as soon as possible, and no later than 30 days after discovery, of a "notification event" involving the unencrypted information of at least 500 consumers. Section 314.6 exempts firms that maintain information on fewer than 5,000 consumers from some requirements, including the written risk assessment and the annual board report, but not from the program itself.

HUD and FHA: 12 hours to report

FHA-approved mortgagees have a short clock. HUD's Mortgagee Letter 2024-10 requires them to report a significant cybersecurity incident to HUD within 12 hours of detection, with set details about the incident and a point of contact. A ransomware event at a servicer or a compromised component in a loan origination platform used by an FHA lender can start that clock. Ginnie Mae issuers and lenders that sell to the government-sponsored enterprises carry their own reporting duties in their program guides; check the current versions you signed up to.

New York: 23 NYCRR Part 500

Title insurers, mortgage bankers, mortgage brokers and servicers licensed by the New York State Department of Financial Services (NYDFS) are covered entities under its cybersecurity regulation, unless an exemption applies. The second amendment, adopted on 1 November 2023, phased in through 1 November 2025. For supply chain work the sections that matter are 500.8 (application security, including procedures for evaluating and testing externally developed applications), 500.11 (third-party service provider security policy), 500.13 (asset inventory, with the full inventory requirement in effect from 1 November 2025), and 500.17 (notice to the superintendent within 72 hours of determining that a cybersecurity incident occurred, plus an annual certification of compliance by 15 April). NYDFS has enforced this rule against a title insurer, which is covered in the incidents section.

Title insurers in other states: the NAIC model law

Many states have adopted the NAIC Insurance Data Security Model Law, which asks licensees, including title insurers in those states, to run an information security program, oversee third-party service providers and notify the insurance commissioner of cybersecurity events. State versions differ in deadlines and exemptions, so read your state's statute rather than the model.

SEC disclosure rules for public REITs and real estate companies

Public REITs, homebuilders, title underwriters and mortgage companies file with the SEC. The cybersecurity disclosure rules adopted on 26 July 2023 require a Form 8-K under Item 1.05 within four business days of determining that a cybersecurity incident is material, and an annual description of cybersecurity risk management, strategy and governance in Form 10-K, including processes to oversee risks from third-party service providers. The incidents below come largely from those filings.

PCI DSS v4.0.1 for rent and fee payments

Any business that accepts card payments for rent, deposits or application fees is in scope for PCI DSS, either directly or through its payment provider. The future-dated requirements of v4.0 became mandatory on 31 March 2025. Three matter most here: 6.3.2 (an inventory of bespoke and custom software and the third-party components in it), 6.4.3 (managing and authorizing scripts on payment pages) and 11.6.1 (detecting unauthorized changes to payment pages). A resident portal that hosts its own payment page is squarely in that territory.

State privacy laws and tenant data

State breach notification laws apply to tenant and buyer data in every state, and comprehensive state privacy laws add security duties. California's privacy agency finalized regulations in September 2025 that include mandatory cybersecurity audits for businesses whose processing presents significant risk, with deadlines phased in by revenue. Large residential operators with California residents should check whether those thresholds reach them.

Federal guidance you can borrow

None of these is binding on a private real estate company, but they make good contract and policy language:

• NIST SP 800-218 (SSDF) version 1.1 gives secure development practices you can require of proptech vendors and apply to your own code.
• CISA's 2026 Minimum Elements for a Software Bill of Materials sets the current baseline for what an SBOM should contain, replacing the 2021 NTIA list. Use it as the format clause when you ask vendors for SBOMs.

Real public incidents from the last three years

The incidents below come from company filings and official statements. They are described only as the sources describe them. None of them proves what any company should have done differently.

A title insurance and escrow platform outage (November 2023)

Fidelity National Financial, one of the largest US title insurance companies, filed a Form 8-K on 21 November 2023 reporting a cybersecurity incident that affected certain systems, and said it had blocked access to some systems while it responded. The filing described disruption to title insurance, escrow and other title-related services, and to mortgage transaction services. In a later amendment the company reported that an unauthorized third party had accessed systems and that it would notify roughly 1.3 million consumers whose information may have been affected. Agents and lenders who closed transactions through those systems felt the disruption during the busy pre-holiday period.

A second title underwriter takes systems offline (December 2023)

First American Financial, another large title insurer and settlement services provider, disclosed in a Form 8-K in December 2023 that it had identified a cybersecurity incident and taken certain systems offline to contain it. The company later reported that an unauthorized third party had accessed some systems and that it would notify about 44,000 individuals. NYDFS separately had fined a First American title insurance subsidiary in November 2023 for violations of Part 500 connected to an earlier exposure of document images, which shows that the regulator applies its cybersecurity rule to title insurers.

Mortgage servicing and origination (October 2023 and January 2024)

Mr. Cooper Group, a large mortgage servicer, disclosed in October and November 2023 filings that it had detected a cybersecurity incident on 31 October 2023, shut down certain systems, and later that customer data had been taken; its notices covered about 14.7 million people. In January 2024, loanDepot disclosed a cybersecurity incident in a Form 8-K that disrupted some of its systems and later reported that about 16.6 million customers would be notified. Borrowers could not make payments through the usual online channels for a period in both cases.

Wire fraud aimed at closings (ongoing)

The FBI's Internet Crime Complaint Center (IC3) tracks real estate fraud as its own category. Its 2024 report counted 9,359 real estate fraud complaints with reported losses of about 173.6 million US dollars, and business email compromise, which often targets closing funds, remained among the costliest categories overall. These schemes usually run through email and impersonation rather than code, but they end at the wire instruction, which is the data that title and escrow software produces.

What the incidents have in common

1. The platform is the dependency. When a title, escrow or servicing platform goes down, agents, lenders and borrowers who never contracted with the affected system still wait. That is supply chain risk seen from downstream.
2. The filings name the clock. Each public company had to decide materiality and file within days, while also notifying states, regulators and, for FHA lenders, HUD within hours.
3. Recovery depends on knowing what runs where. Taking systems offline and bringing them back safely requires an inventory of systems, components and vendor connections, which is the first job of the plan below.

The personas who own the problem

Supply chain security in real estate fails when everyone assumes someone else owns it. Six roles share it. For each, here is what they need and when the need lands.

The CISO

At a REIT, a large property manager, a brokerage group, or a title or mortgage company, the CISO owns the risk register, the board report and the incident call. The CISO needs one number that answers "how exposed are we through software we did not write", a vendor tier list, and an incident plan that already knows which systems produce wire instructions and which store tenant screening data. The need lands at the annual Safeguards Rule board report, before a 10-K filing, at an NYDFS certification on 15 April, and at 2 a.m. when a vendor sends an incident notice.

The VP or Director of Engineering

At a proptech company, or a digital team inside an operator, this is the person who ships the resident app, the payment portal, the leasing site and the integrations. They need a single process for dependencies, findings and fixes that does not stall releases, and a short answer when a customer's security team asks for an SBOM. The need lands when a critical library CVE drops, when a large customer's security review stalls a renewal, and when a new integration partner sends its questionnaire.

The GRC or compliance lead

This person maps controls to the FTC Safeguards Rule, Part 500, PCI DSS, SOC 2 reports for customers, and state privacy law. They need evidence by clause: the inventory for 314.4(c)(2), testing for 314.4(c)(4) and (d)(2), service provider assessments for 314.4(f), and exception records with an owner and an expiry. The need lands before the annual board report, the NYDFS certification, a PCI assessment and every customer audit.

The procurement or vendor risk owner

Real estate buys most of its software, so this role carries a large share of the work. They need a vendor register tiered by data and impact, contract clauses for SBOMs, vulnerability notice and patch timelines, and a way to chase the evidence without spreadsheets. The need lands at contract signature and renewal, at a vendor's incident notice, and when a new building integrator or screening provider is onboarded.

Building technology and facilities IT

In commercial real estate, building automation, access control and cameras often sit with facilities, not IT. This role needs an asset list of controllers, servers and management software with firmware and software versions, a channel to the integrator for patches, and network segmentation that keeps building systems away from corporate and tenant networks. The need lands when an advisory names a controller they run, when a tenant's security team asks about badge systems, and at a building acquisition.

The startup CTO who also owns compliance

At an early proptech company, one person runs engineering, security and the SOC 2 project. They need what is enough for this stage: an SBOM per release, a vulnerability gate in CI, a short vendor list, and a public page that answers security questionnaires once. The need lands at the first enterprise or institutional customer, at the first SOC 2 audit window, and when a property management partner asks for a security review before an integration goes live.

Step by step: a 30, 60 and 90 day plan that works with any tools

This plan works with spreadsheets, open source tools or a platform. The goal is a working program and evidence at day 90, not a perfect inventory.

Days 1 to 30: see what you run

1. Name the owners. Assign one owner for the software you build, one for the software you buy, one for building systems and one for evidence. Write it down; the Safeguards Rule calls the program lead the qualified individual.
2. Inventory built software. List every repository, container image and mobile app you ship, including the resident portal, payment pages, listing sites and integration services. Generate an SBOM for each in SPDX or CycloneDX format and store it with the release.
3. Inventory bought software. Start from accounts payable and single sign-on: every vendor you pay and every SaaS app your staff log into. Add the PMS, accounting, screening, payments, CRM, transaction management, title and escrow, loan origination, and building systems.
4. Tier vendors. Use four tiers. Critical: produces or changes money movement, wire instructions or physical access. High: holds consumer reports, bank data or identity documents. Medium: holds other personal data. Low: everything else.
5. Find the payment pages. List every page where a tenant or buyer enters card or bank details, who hosts it and which scripts load on it.
6. Map incident clocks. Write the reporting deadlines that apply to you on one page: HUD 12 hours, NYDFS 72 hours, FTC 30 days, SEC four business days after a materiality determination, and state breach notice laws.

Days 31 to 60: control what changes

1. Set a patch clock. Agree timelines by risk, then write them into policy and contracts. The table below is an example to adapt, not a regulatory requirement.

2. Gate releases. Add a dependency scan to CI for every built application. Start in report-only mode for two weeks, then block on KEV-listed and critical findings that have a fixed version.
3. Record exceptions. Every finding you will not fix in time gets an owner, a reason, a compensating control and an expiry date. This becomes the exception register auditors ask for.
4. Put SBOM and notice clauses in contracts. For critical and high vendors, require an SBOM in SPDX or CycloneDX aligned to CISA's 2026 minimum elements, notice of exploited vulnerabilities within a set number of days, a patch timeline, and notice of incidents in time for your own regulatory clocks.
5. Secure the payment pages. Keep an inventory of scripts on each payment page with a reason for each, and put a change detection mechanism in place, as PCI DSS 6.4.3 and 11.6.1 require.
6. Segment building systems. Put building automation and access control on their own network segments, remove direct internet exposure, and require integrators to use managed remote access.

Days 61 to 90: prove it works

1. Run a tabletop. Use the illustrative scenario below. Time how long it takes to answer "are we affected" and "which vendors are".
2. Measure. Track open KEV findings past the clock, percentage of built applications with a current SBOM, percentage of critical vendors with an SBOM on file, and open exceptions past expiry.
3. Assemble the evidence. Map each control to the clause it answers: Safeguards Rule 314.4, Part 500 sections, PCI DSS requirements and SOC 2 criteria.
4. Report. Give the board or owner a one-page summary with the four measures, the top five vendor risks and the decisions you need.
5. Publish what customers ask for. If you sell software to property managers, lenders or brokers, publish a security page with your controls and documents so you answer questionnaires once.

Illustrative scenario: a library CVE in the resident portal on a Friday

This is an invented example with round numbers. On a Friday afternoon a critical vulnerability in a widely used web framework library is added to CISA's KEV catalog. A property manager with 40,000 units runs a resident portal built by its own team and a PMS bought from a vendor.

• With an inventory, the engineering lead searches the SBOMs and finds the library in the portal's payment service and in two internal tools. Reachability shows the portal calls the vulnerable function. The fix version exists; the team opens a pull request, the gate passes, and the fix ships Saturday.
• The vendor risk owner checks the PMS vendor's last SBOM, sees the same library, and sends a notice under the contract clause asking for the vendor's assessment and patch date.
• The GRC lead records an exception for one internal tool that cannot be upgraded until a dependency moves, with a compensating control and a 14 day expiry.
• Without an inventory, the same Friday starts with emails asking every team and vendor whether they use the library, and the answer arrives days later.

How Safeguard does this

Everything above works without Safeguard. This section shows the same plan in Safeguard, using only flows from docs.safeguard.sh. Every capability named here is generally available (GA). Commands are copied as the docs show them; we did not run them for this post.

1. Inventory the software you build

Safeguard's Enterprise Software Supply Chain Manager (ESSCM) generates SPDX and CycloneDX SBOMs (SBOM generation and analysis, GA) and runs software composition analysis (SCA, GA) across each project's full transitive dependency tree. Per the docs, you connect repositories or container registries under Integrations, or upload files, and Safeguard creates the project and its SBOM. Continuous scanning re-evaluates projects when vulnerability data changes, so a new KEV entry is matched against existing SBOMs without a new build.

If a cloud service may not clone your repositories, the local runner (GA) built into the Safeguard CLI (GA) runs scan jobs on your own machine and uploads only the SBOM and findings, not source code. The docs show:

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash

# start the interactive terminal, then type /login
safeguard

For a server without a terminal UI, the docs show:

safeguard runner start --workspace ./path/to/repo
safeguard runner status

Safeguard also offers on-prem and fully air-gapped deployment (GA) and Zero AI mode (GA), in which the platform runs with no large language model in the loop. Lenders and title companies with strict data handling rules can keep code and findings inside their own environment.

2. Prioritize by exploitation and reachability

Vulnerability management (GA) enriches findings with EPSS and CISA KEV status, and reachability analysis and prioritization (GA) adds whether your application calls the vulnerable code path. Together they fill the top rows of the patch clock table. SAST (GA) covers your own portal, payment and integration code. DAST (GA) tests targets you have verified, such as a staging resident portal. License compliance (GA) flags obligations in the components you ship, which matters to proptech vendors whose customers review licenses during procurement.

3. Turn the patch clock into policies and gates

Policies, gates and guardrails (GA) put the patch clock into the pipeline. Per the docs, you go to Settings › Policies, click Create Policy, define conditions such as severity, CVSS, EPSS and license in the visual builder or YAML, and set the action.

Each policy has one action that decides what a failure does to the gate:

A reasonable mapping: Block for KEV-listed or critical findings with a fix in internet-facing applications such as the resident portal, Warn for high, Notify for the rest. The docs show this GitHub Actions workflow:

name: Safeguard
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Safeguard scan
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
          SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
        run: |
          set -eu
          curl -fsSL https://cli.safeguard.sh/install | bash
          "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

Drop --fail-on critical for report-only mode in the first weeks, matching day 31 of the plan. The API key is created under Settings › Developer with the scans:trigger and scans:read scopes.

4. Run exceptions through a recorded approval

Approval runs through exceptions. Per the docs, a developer clicks Request Exception, selects the policy and finding, gives a justification and an expiration date, and submits; approvers decide and the audit trail records it.

For findings you will not fix yet, the Mitigations tab records the type (Risk Acceptance, False Positive, Workaround Applied or Not Applicable), justification, approver, an optional expiry for risk acceptances, and evidence. That is the GRC lead's exception register for 314.4 and Part 500 reviews.

5. Fix faster where a fix exists

Autonomous remediation (GA) opens fix pull requests that move a vulnerable dependency to a fixed version, one repository at a time or in bulk. It ships switched off, with every category set to Manual, so nothing changes until your team turns it on.

6. Bring vendors inside the clock with TPRM

Third-Party Risk Manager (TPRM, GA) is where the vendor risk owner works. Per the docs:

1. Vendors › Add Vendor records the company, contact, products used and risk tier (Critical, High, Medium, Low), with CSV import for a register that started in a spreadsheet. Contract records hold dates, SLA terms, security requirements and SBOM obligations.
2. Request SBOM, or Bulk Request for many vendors, sends a request setting the SPDX or CycloneDX format, required fields and a deadline, with reminders around the deadline.
3. An arriving SBOM is validated for format and completeness and scanned for vulnerabilities; Request Revision returns one that falls short.
4. Monitoring alerts on new critical vulnerabilities and CISA KEV additions that affect a vendor's SBOM, and reassessment can be triggered by contract renewals and security incidents.

That is the 314.4(f) and Part 500.11 work in one place: the PMS vendor, the screening provider, the payments provider and the building integrator each with a tier, an SBOM and a clock.

7. Map the evidence

The Compliance and GRC suite (GA) holds frameworks, controls, evidence and tests. Per the docs, you open a framework on Compliance › Frameworks, see which connected systems answer its tests, and run tests on schedule or with Run now on Compliance › Tests. The docs say a passing result is evidence toward a control, not proof that it is met. Check the framework library for the frameworks you answer to, and map Safeguards Rule and Part 500 clauses to its controls where a dedicated framework is not listed.

Portal audit trails (GA) log SBOM activity, access and administrative changes. Per the docs, you view them on Settings › Audit Logs and export as CSV, JSON or PDF for the evidence folder.

8. If you sell software to real estate, answer your customers once

Proptech vendors answer questionnaires from property managers, lenders and brokerages every week. Trust Center (GA) publishes a page with your compliance status, controls, policies, subprocessors and documents. Per the docs, you manage it on Compliance › Trust Center and publish explicitly; nothing goes live on its own. Portal (GA) handles sharing the SBOMs you publish with customers.

What Safeguard does not do

• It does not patch vendor software you run. A PMS, escrow platform, access control server or building controller fix comes from that vendor or integrator. Safeguard can show exposure through vendor SBOMs; your team or provider applies the patch.
• It does not stop wire fraud or business email compromise. Callback verification of wire instructions, email authentication and staff training are separate controls.
• It does not monitor payment pages in the browser. PCI DSS 6.4.3 and 11.6.1 need a mechanism that watches what the tenant's browser receives. Safeguard's docs describe no such browser-side monitoring, so plan a separate control.
• It does not see inside vendor SaaS without the vendor's help. If a vendor will not provide an SBOM, Safeguard cannot invent one. TPRM tracks the request and its status; your contract is what gets it delivered.
• It does not inventory building controllers on the network. Firmware on door controllers and building automation panels needs an asset list from the integrator or an operational technology tool.
• It does not make regulatory decisions. Materiality, HUD and NYDFS notices, FTC notification and state breach notices belong to your counsel and executives.

Common mistakes

1. Treating the PMS vendor's SOC 2 report as the whole answer. A SOC 2 report describes controls over a period. It does not list the components in the product or say how fast the vendor patches a KEV entry. Ask for both.
2. Leaving building systems out of scope. Access control and building automation are bought by facilities and installed by integrators, so they rarely appear in IT inventories, yet they control physical access.
3. Gating on day one. Turning on blocking gates before teams have seen the findings stalls releases and gets the gate removed. Start in report-only mode.
4. Writing exceptions without expiry. An exception with no end date is a permanent risk acceptance. Every exception needs an owner and a date.
5. Forgetting the short clocks. HUD's 12 hours and NYDFS's 72 hours start before the investigation ends. Write the contact list and the decision owner in advance.
6. Asking vendors for "an SBOM" without a format. Specify SPDX or CycloneDX, the minimum elements, the delivery cadence and what triggers an update.
7. Assuming a hosted payment page removes all duties. Even with a hosted payment provider, the merchant still owns its own website's scripts and its PCI validation.

FAQ

What is software supply chain security for real estate companies?

It is the practice of knowing which software components and vendors your property, brokerage, title or lending operations depend on, keeping them patched on a set clock, and proving it. It covers the code you build, such as resident portals and payment pages, and the systems you buy, such as property management, escrow and access control.

Does the FTC Safeguards Rule apply to real estate businesses?

It applies to financial institutions under FTC jurisdiction, which in real estate typically includes mortgage brokers, non-bank lenders and servicers, and other firms that provide financial products to consumers. Whether a specific brokerage, property manager or appraiser is covered depends on its activities, so confirm with counsel.

What does the Safeguards Rule say about vendors?

Section 314.4(f) requires you to select service providers capable of maintaining appropriate safeguards, require those safeguards by contract, and periodically assess them. In practice that means a vendor register, contract clauses and reassessment on a schedule.

How fast must FHA lenders report a cyber incident to HUD?

Mortgagee Letter 2024-10 requires FHA-approved mortgagees to report a significant cybersecurity incident to HUD within 12 hours of detection.

Do title insurers have cybersecurity rules?

Yes, through state insurance law. Title insurers licensed in New York are covered by 23 NYCRR Part 500, and many other states have adopted versions of the NAIC Insurance Data Security Model Law.

Should a property manager ask its PMS vendor for an SBOM?

Yes, for critical and high tier vendors. Ask for SPDX or CycloneDX aligned with CISA's 2026 minimum elements, an update cadence, and a commitment to notify you of exploited vulnerabilities in the product.

Does PCI DSS apply to rent payments?

If you accept card payments for rent or fees, yes, either directly or through your payment provider. Requirements 6.4.3 and 11.6.1, mandatory since 31 March 2025, cover scripts and changes on payment pages.

How do smart building systems fit into supply chain security?

Building automation and access control run vendor software and firmware that age in place. Include them in the inventory, segment them from corporate and tenant networks, and write patch and remote access terms into integrator contracts.

Can Safeguard scan our code without sending it to the cloud?

Yes. The local runner (GA) built into the CLI scans on your own machine and uploads only the SBOM and findings, and on-prem and air-gapped deployment (GA) keep the whole platform in your environment.

Many of these risks come down to components you build and ship with known fixes, or with no fix yet. The block below explains how Safeguard closes both gaps for the open source inside resident portals, payment flows and proptech products.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session: ask "fix the lodash CVE in this repo", and the CLI reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. A resident portal or proptech team would use the same flow on its own repository.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, and scans from the terminal: the route for lenders and title companies that will not give a cloud service repository access.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: send work to a computer running the CLI and approve the command on the phone with Allow once, Allow for turn or Deny. It suits an engineering lead on call for a resident app over a weekend.

Click through it at your own pace, or open it full screen.

Quick check

Related reading

• Real estate and proptech supply chain in 2026
• Real estate and proptech security considerations
• Smart building automation security for proptech
• The Mr. Cooper mortgage data breach

Sources

• eCFR: 16 CFR Part 314, Standards for Safeguarding Customer Information

To try the flows in this guide, download Safeguard at https://safeguard.sh/download and read the documentation at https://docs.safeguard.sh/docs .

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.