Category: Cybersecurity

A familiar company name in an email’s From line is not proof that the company sent it. Domain-based Message Authentication, Reporting, and Conformance, or DMARC, gives mail systems a way to test whether a message is authorized to use the domain in that visible address. It combines two older mechanisms, SPF and DKIM, with a check called alignment.

That can make direct impersonation of a domain much harder. It cannot tell you whether an authenticated message is honest, whether an account has been compromised, or whether a similar-looking domain belongs to the organization you think it does. Understanding that boundary is especially useful now that the IETF’s 2026 DMARC specification has replaced the older RFC 7489.

What SPF and DKIM actually authenticate

SPF lets a domain publish which sending systems are allowed to send mail using a particular SMTP envelope identity. That identity, called MAIL FROM, is not necessarily the address a reader sees in the From line. A successful SPF check for an unrelated domain therefore does not, by itself, prove the visible sender’s domain is authorized.

DKIM uses a cryptographic signature attached to the message. The receiving system can check that signature against a public key published in DNS. A valid signature links the message to the signing domain, but that domain can also differ from the one displayed to the recipient.

The IETF DMARC standard joins these pieces to the visible From domain. It does not authenticate the person named before the address, the mailbox’s local part, or the contents of the message. This is a domain-level control, not a universal identity certificate.

Alignment is the missing link

Suppose a message visibly says it comes from news.example.com. An SPF pass for an unrelated mailing service’s own domain would not satisfy DMARC just because that service is legitimately allowed to use its own servers. The authenticated domain must also align with the visible From domain. The same idea applies to DKIM’s signing domain.

DMARC can pass when either SPF or DKIM both passes authentication and aligns with the From domain. It does not require both paths to pass every time. Under relaxed alignment, related subdomains can share the same organizational domain; strict alignment demands an exact domain match. Domain owners can specify which alignment mode they want.

That distinction explains a common troubleshooting puzzle: a message may show a valid SPF result and still fail DMARC because the SPF-authenticated domain belongs to the service provider rather than to the sender’s visible domain. The relevant comparison is between authenticated identities and the domain in the From address, not between the display names a user sees.

Policies express a preference, not absolute control

A domain owner publishes DMARC information as a DNS TXT record at a name beginning with _dmarc. Its policy can request no special handling of failures (p=none), suspicious treatment such as quarantine (p=quarantine), or rejection (p=reject). The difference matters: p=none is useful for observing mail streams, but it is not an instruction to block spoofs.

The receiver still makes the final delivery decision. The new IETF standard says a DMARC pass is not a safety verdict, and even a published reject policy must be weighed with other information by a receiving system. Legitimate mail can fail authentication in some indirect delivery paths. Conversely, a malicious message from an authenticated account can pass.

There is another DNS distinction worth keeping clear. Publishing a DMARC TXT record does not make the entire connection secure. Our DNSSEC explainer describes a separate mechanism for authenticating DNS data and its own limits.

Reports turn a policy into an operational process

Domain owners can request aggregate feedback reports about messages claiming to use their domain. The reporting format is defined in RFC 9990. Those reports summarize observed sending sources, authentication outcomes and receiver handling, helping owners find legitimate systems that have been forgotten as well as apparent abuse.

Reports are not an infallible census. Participating receivers are not obliged to send every requested report, and the resulting data may require interpretation. A familiar third-party sender can fail alignment because of configuration, while an unfamiliar source may need investigation before anyone labels it malicious. The reporting specification also discusses privacy implications when an outside service processes this metadata.

A careful rollout inventories ordinary mail, newsletters, account notifications and services that send on the organization’s behalf. It starts by monitoring and fixing legitimate failures, then evaluates whether quarantine or reject is appropriate. The IETF specification calls for a long observation period before reject for domains whose users may post to mailing lists; Google’s rollout guide likewise recommends reviewing reports and moving gradually from monitoring to enforcement. The right duration depends on actual mail flows, not a universal countdown.

Forwarding and mailing lists complicate the picture

Mail that is forwarded can arrive from a server that the original sender did not authorize in SPF. A DKIM signature may still survive if the message is not changed, but a mailing list that edits the body or headers can invalidate it. This is why a sudden switch to p=reject can disrupt legitimate conversations even when direct mail appears healthy.

The 2026 specification’s interoperability discussion explicitly warns about forwarded mail, aliases and mailing lists. It advises domain owners not to rely on SPF alone when considering reject. In practical terms, the sending setup and its indirect routes need testing; a neat DNS record is only one part of the job.

Major mail providers have their own sender rules as well. Gmail’s current sender guidelines require SPF or DKIM for all senders to Gmail accounts and SPF, DKIM and DMARC for senders above its bulk-sender threshold. These delivery requirements are not the same thing as a guarantee that every authenticated message will reach the inbox.

What DMARC leaves for other defenses

An attacker can register a visually similar domain and authenticate mail for that domain. They can also put a trusted organization’s name in the human-readable display-name field while using a different address. DMARC was designed to address unauthorized use of the exact From domain, not these lookalike or display-name attacks. It does not inspect links or attachments for harm.

Nor does a DMARC pass guarantee that the sender’s account was used with permission. The domain may have authorized its mail service perfectly while an account on that service is compromised. The meaningful lesson for readers is to treat authentication as evidence about domain use, then judge unusual requests through other channels. Passkeys and account recovery address another part of the identity problem, but they do not replace email-domain authentication.

What to watch next

RFC 9989 and its separate aggregate-reporting specification give operators an updated reference, but publication of a standard does not mean every mail system instantly changes behavior. Watch how receivers handle indirect mail, whether services make aligned signing easier, and whether reporting tools turn aggregate data into reliable operational decisions without obscuring its limits.

For everyday readers, the enduring distinction is simpler. DMARC helps answer whether a domain authorized its appearance in an email’s From address. It does not answer whether the message deserves your trust. This article explains standards and vendor guidance; it does not claim to have tested a particular mail provider or domain configuration.

Primary and authoritative sources

• IETF RFC 9989: DMARC protocol, 2026
• IETF RFC 9990: DMARC aggregate reporting
• Google: Email sender guidelines
• Google Workspace: Recommended DMARC rollout

Featured image is an AI-generated editorial metaphor, not a photograph of an actual email filtering device.

The small date inside a website’s TLS certificate is becoming an operational deadline that arrives much more often. Publicly trusted certificates once lasted for years. The current maximum is now 200 days for certificates issued from March 15, 2026, and the industry schedule continues to 100 days in 2027 and 47 days in 2029.

Shorter lifetimes reduce the time that stale or misissued certificates can remain accepted. They also expose fragile operations. A team that still renews certificates by calendar reminder, copies files by hand, or checks only the public homepage may discover that a 47-day certificate is less a cryptography problem than an automation test.

The reduction is already underway

The adopted CA/Browser Forum ballot SC-081v3 created a staged schedule for publicly trusted TLS server certificates. Its updated Baseline Requirements set a maximum of 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029.

The schedule also shortens how long a certification authority can reuse domain and IP address validation data: 200 days in the current stage, 100 days from 2027, and 10 days from 2029. Renewal and validation are related but distinct. A certificate can need replacement before ownership evidence can be reused, and future automation must handle both.

These limits apply to public TLS certificates covered by the Web PKI Baseline Requirements. A private certificate authority used inside an organization follows its own policy, although the same lifecycle lessons still matter.

Short lifetimes reduce exposure, not every risk

A certificate binds a public key to a domain name for a defined period. If the private key is stolen, the domain changes hands, or issuance was incorrect, a shorter lifetime narrows how long that certificate can remain naturally valid. It also makes cryptographic transitions easier because old certificates leave the ecosystem sooner.

Expiration is not a substitute for revocation. A known compromised key should still trigger revocation and replacement. Short lifetimes provide a dependable outer bound because browsers enforce the certificate’s not-before and not-after dates, while online revocation checks can face availability, privacy, and timeliness limitations.

Certificate Transparency is also complementary. CT logs can make public issuance visible, but visibility does not rotate a stolen key, deploy a replacement, or prevent an expired certificate from taking a service offline.

ACME turns issuance into a protocol

The Automatic Certificate Management Environment, or ACME, is the standard protocol that lets software create an account, order a certificate, prove control of identifiers, obtain the certificate, and perform management actions without a person following a certificate authority’s web form.

ACME is necessary infrastructure for short-lived certificates, but completing an order is only the first step. A production system must place the certificate and private key on every TLS endpoint, reload or restart the correct service, preserve permissions, retain a rollback path, and verify that clients actually receive the new chain.

That distinction matters in layered systems. TLS may terminate at a content-delivery network, cloud load balancer, ingress controller, reverse proxy, application server, mail gateway, appliance, or several of them. A successful renewal on one machine does not prove that every endpoint changed.

Renew early, retry gradually, and avoid synchronized waves

A robust process does not wait until the final day. The Let’s Encrypt integration guide recommends using ACME Renewal Information when supported and otherwise renewing automatically with part of the certificate lifetime still available. That margin absorbs temporary outages, DNS delays, rate limits, and deployment failures.

Retries should use backoff rather than hammering the certificate authority. Large fleets should spread renewals across small batches instead of creating one monthly event. Randomized schedules reduce load spikes and prevent a single provider outage or configuration error from affecting the entire certificate population at once.

The process also needs an emergency path. Operators should be able to request an early renewal, revoke a compromised certificate, pause a faulty rollout, and restore the last known-good configuration without waiting for the normal scheduler.

Domain validation determines the security boundary

HTTP-01 validation places a temporary token on a web server. DNS-01 creates a TXT record and supports wildcard certificates, but automation often requires DNS API access. The current Let’s Encrypt challenge guide recommends narrowly scoped credentials or a separate validation service rather than placing unrestricted DNS credentials on every web server.

That is an important tradeoff: automating certificate renewal should not create a credential capable of rewriting an entire DNS zone from a compromised application host. Delegating the ACME challenge name to a dedicated zone can reduce the blast radius.

DNSSEC can authenticate DNS responses, but it does not authorize an ACME client or safely store DNS API credentials. The validation method, credential scope, authoritative DNS availability, and propagation behavior still need separate engineering.

Deployment needs zero-downtime rotation

Certificate files should be written atomically so a service never reads half of a new chain. On redundant infrastructure, replace and test a subset of endpoints before broad rollout. Long-lived connections may continue using the old certificate until they reconnect, which is normally harmless while both certificates remain valid.

Private-key strategy should be explicit. Reusing a key can simplify some systems, while generating a fresh key limits the value of an older key if it was copied. Hardware security modules, managed load balancers, and cloud certificate services may impose different workflows. The right choice depends on threat model and platform capabilities, but it should not be accidental.

Chain selection matters too. A server can install the new leaf certificate while serving an incomplete or incompatible intermediate chain. Testing must include multiple client types and a handshake from outside the deployment environment.

Monitoring must verify the certificate clients see

An automation job reporting success is not the same as a successful deployment. External monitoring should check the hostname, presented chain, expiration time, expected issuer or policy, and coverage of every important endpoint. Alerts need enough lead time for investigation and must reach someone who can act.

Inventory is the foundation. Include public websites, APIs, alternate hostnames, IPv6 endpoints, legacy appliances, disaster-recovery sites, and third-party services. Like an SBOM for software components, a certificate inventory is not a security guarantee, but it makes unmanaged dependencies visible.

Teams should also rehearse failure. Block validation, remove a DNS permission, break a deployment hook, and confirm that monitoring detects the problem while the existing certificate still has time left. A renewal pipeline that has never failed in testing may simply have untested failure handling.

Short certificates are already practical

Let’s Encrypt announced a move from its familiar 90-day default toward 45-day certificates and advised users to verify that clients do not rely on hardcoded renewal intervals. Its guidance specifically warns that a client renewing every 60 days cannot manage a 45-day certificate.

This illustrates the larger change. Automation should derive behavior from the certificate and renewal service, not assume a fixed lifetime. A shorter certificate should cause more frequent routine cycles, not more emergency work.

Limitations and what to watch next

Shorter validity does not stop an attacker who controls a domain’s DNS or hosting account from requesting another certificate. It does not protect a compromised server after a valid handshake, fix weak application authentication, or secure private trust systems outside public-browser rules.

Watch for broader ACME Renewal Information support, safer persistent DNS validation methods, certificate management integrated into load balancers and orchestration platforms, and dashboards that verify deployment rather than merely issuance. The operational goal is not to renew certificates more often by hand. It is to make issuance, validation, deployment, verification, alerting, and recovery one continuously tested system.

Featured image: AI-generated editorial visualization of automated certificate replacement across unbranded web infrastructure. It is not a diagram of a specific provider or a hands-on security test.

Primary and authoritative sources

• CA/Browser Forum: Ballot SC-081v3
• CA/Browser Forum: TLS Baseline Requirements schedule
• IETF RFC 8555: Automatic Certificate Management Environment
• Let’s Encrypt: Decreasing Certificate Lifetimes to 45 Days
• Let’s Encrypt: Integration Guide
• Let’s Encrypt: Challenge Types

A security scanner can produce thousands of findings, each decorated with a severity label and a decimal score. The natural response is to patch every item marked critical before touching anything rated lower. That rule is simple, auditable, and often wrong.

The Common Vulnerability Scoring System, or CVSS, describes technical severity. It does not know whether a vulnerable product is installed in your environment, exposed to the internet, protected by another control, or supporting a safety-critical service. It also does not necessarily tell you whether attackers are exploiting the flaw today. A better patch queue combines CVSS with evidence of active exploitation, a forecast of likely exploitation, and local knowledge about the affected asset.

CVSS describes a vulnerability’s technical characteristics

CVSS gives security teams a common language for discussing software, hardware, and firmware vulnerabilities. In version 4.0, the Base metrics capture intrinsic characteristics such as attack requirements and potential impact. Threat metrics can reflect changing information such as exploit maturity, while Environmental metrics adapt the assessment to a particular deployment. Supplemental metrics add context without changing the score.

The official CVSS 4.0 specification says consumers should enrich Base metrics with threat and environmental information. It also lists factors outside CVSS, including regulatory obligations, customers affected, possible financial loss, threats to life or property, and reputational impact. The US National Vulnerability Database puts the distinction even more directly in its CVE frequently asked questions: CVSS is a qualitative measure of severity, not a measure of risk.

A Base score is still valuable. It helps compare the inherent consequences and exploit conditions of different flaws using a transparent vector. The mistake is treating that useful input as a complete work order.

Confirmed exploitation changes the priority

The Cybersecurity and Infrastructure Security Agency maintains the Known Exploited Vulnerabilities Catalog, usually shortened to KEV. An entry means CISA has evidence that attackers have exploited the vulnerability in the wild, that a clear remediation action exists, and that the vulnerability meets the catalog’s inclusion criteria. This is a stronger urgency signal than a theoretical possibility or public proof-of-concept alone.

CISA created the catalog through Binding Operational Directive 22-01. Its deadlines apply to covered US federal civilian agencies, but CISA recommends that other organizations use KEV as an input to vulnerability management. The important idea travels well: remediation capacity should focus first on vulnerabilities that attackers have demonstrated they can use.

KEV is not a complete inventory of everything dangerous. It is deliberately evidence-based and retrospective. A newly disclosed flaw may deserve urgent action before it reaches the catalog, and an attacker may exploit vulnerabilities that public sources have not yet confirmed.

EPSS estimates near-term exploitation probability

The Exploit Prediction Scoring System, or EPSS, addresses a different question. Maintained by the Forum of Incident Response and Security Teams, it uses a data-driven model to estimate the probability that exploitation activity for a published CVE will be observed in the next 30 days. Scores are updated daily and are available through public data feeds.

According to the official EPSS overview, the model uses empirical signals associated with attacker behavior and ongoing activity. A probability score is not the same as its percentile ranking. Probability estimates the absolute likelihood of observed exploitation; percentile shows how the score ranks against other vulnerabilities.

EPSS and KEV should not be forced into agreement. The EPSS guidance describes KEV as confirmed historical evidence and EPSS as a forward-looking forecast. A KEV entry can have a low current EPSS score without contradiction. When direct evidence of active exploitation exists, that evidence takes precedence over a forecast.

Your environment determines the consequence

A flaw cannot harm an organization through a product it does not run. Even when the product is present, reachability and consequence vary. An internet-facing identity server is a different target from an offline test machine. A vulnerable library loaded by a public application matters more than the same library sitting unused in an archive.

Asset context should answer four practical questions. Is the vulnerable component actually present? Can an attacker reach it? What privileges or business process could exploitation affect? Which controls would block, detect, or contain the attack? These answers can raise or lower urgency without changing the underlying CVSS Base score.

This is why an accurate software inventory matters. Our guide to software bills of materials explains that an SBOM can help locate components but cannot prove they are exploitable or safe. Inventory starts the investigation; deployment context completes it.

A layered patch queue works better than one cutoff

A practical workflow begins by matching scanner findings against a verified asset inventory. Remove obvious false positives, identify externally reachable systems, and connect each asset to an owner and business function. Then layer the signals rather than multiplying them into a mysterious master number.

First, elevate vulnerabilities on CISA KEV or supported by reliable evidence of active exploitation. Within that group, prioritize internet exposure, privileged systems, sensitive data, safety consequences, and weak compensating controls. Next, use EPSS to rank vulnerabilities without confirmed exploitation, while keeping CVSS impact and local consequences visible. Finally, schedule the remaining work according to severity, exposure, maintenance windows, and vendor support.

This ordering is not universal. A hospital, factory, small publisher, and cloud provider have different consequences and downtime constraints. The method should produce a documented queue that engineers can explain, not an opaque score that nobody can challenge.

Patch speed is only one part of remediation

Installing an update can introduce downtime or compatibility failures, especially in operational technology and older appliances. When immediate patching is unsafe, teams may isolate the service, disable a feature, block an attack path, increase monitoring, or retire the asset. Those compensating controls should have owners, evidence, and expiration dates.

Validation matters after the change. Confirm that the vulnerable version is gone, the service restarted correctly, exposure did not move to another instance, and the scanner sees the new state. Our article on continuous threat exposure management explains why remediation should be tested as a reduction in reachable exposure rather than counted as a closed ticket.

Common shortcuts produce misleading priorities

One shortcut is patching every CVSS 9 or 10 while ignoring lower-scored flaws with active exploitation. Another is treating the absence of a KEV entry as proof that a vulnerability is not exploited. A third is reading an EPSS percentile as an exploitation probability. These values answer different questions.

Multiplying CVSS and EPSS is also a poor shortcut. The EPSS maintainers caution that a calibrated probability multiplied by an ordinal severity score does not create an interpretable risk value. Keep likelihood, technical impact, and local consequence as separate visible inputs so reviewers can understand why an item moved up or down.

Limitations and what to watch next

No public feed sees every attack. KEV requires confirmation and can lag a fast campaign. EPSS learns from observable data and cannot know the details of a specific organization’s network. CVSS vectors can be incomplete, disputed, or based on a worst-case default. Asset inventories also drift as cloud services, containers, and third-party software change.

Watch for wider adoption of CVSS 4.0 Threat and Environmental metrics, faster machine-readable vendor advisories, better component-to-asset mapping, and clearer evidence behind exploitation claims. Teams should also measure whether their prioritization method catches exploited vulnerabilities with a sustainable amount of work, then adjust thresholds as their environment and threat landscape change.

A critical severity score deserves attention, but it is not a stopwatch. The best patch decision combines what a flaw could do, whether attackers are using or likely to use it, where it exists, and what failure would mean to the organization.

Featured image: AI-generated editorial illustration of a conceptual vulnerability-triage workflow, not a screenshot of a specific security product.

Primary sources

• FIRST: CVSS v4.0 Specification Document
• NIST NVD: CVE Frequently Asked Questions
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: Binding Operational Directive 22-01
• FIRST: Exploit Prediction Scoring System
• FIRST: EPSS Frequently Asked Questions

Secure Boot is often presented as a single switch that makes a computer’s startup trustworthy. The switch matters, but the label is easy to overread. Secure Boot checks whether early software is authorized by the platform’s key policy. It does not prove that signed firmware has no vulnerability, monitor everything after startup, or guarantee that a damaged device can repair itself.

A resilient platform needs a larger loop: protect firmware from unauthorized changes, detect corruption that still occurs, and recover to a known-good state. That is the difference between a device that blocks one bad bootloader and one that can survive a failed update or destructive firmware attack.

Firmware controls the machine before the operating system

Platform firmware initializes processors, memory, storage, and peripheral devices before the operating system starts. Its privileged position makes compromise unusually serious. Malware below the OS can evade tools that depend on the OS, while careless corruption can leave the computer unable to boot at all.

NIST SP 800-147 focuses on preventing unauthorized BIOS modification and authenticating firmware updates. It also notes a boundary that remains important: system firmware, option ROMs, UEFI drivers, and firmware inside other devices may not all be covered by one mechanism.

That scope question should be the first one asked of any “hardware-secured” product. A chain is only as broad as the components it actually verifies.

What UEFI Secure Boot verifies

The UEFI specification defines Secure Boot policy variables and signature databases. In a typical PC, a platform key establishes ownership, a key-exchange database authorizes changes, an allow database identifies accepted images or signers, and a forbidden database revokes known-bad images.

During startup, the firmware checks executable images against this policy before allowing them to run. That can stop an altered or unauthorized bootloader from taking control ahead of the operating system.

A valid signature establishes provenance and integrity relative to a key. It does not establish that the code is free from logic errors. This is the same distinction that appears in certificate transparency: cryptographic evidence can reveal who authorized an object without making every authorized object safe.

Trust databases need maintenance and revocation

A platform may trust many publishers and historical boot components. If one approved component later proves vulnerable, simply leaving Secure Boot enabled is not enough. The device needs a safe way to update its forbidden-signature database and stop accepting that component.

Revocation creates a deployment problem. Blocking an old loader before a compatible replacement is installed can make a working device unbootable. Updating the replacement first but delaying revocation leaves an attack window. Vendors need staged updates, dependency checks, rollback planning, and clear failure handling.

Keys also have lifecycles. Manufacturers and platform owners need protected generation, storage, rotation, delegation, and emergency replacement. An attacker who can authorize new keys can turn a signature check into an approval service for malicious code.

Verified Boot and Measured Boot answer different questions

Verified Boot enforces policy: an unauthorized component is blocked. Measured Boot records cryptographic measurements of startup components, usually extending them into registers in a Trusted Platform Module. A verifier can later compare signed evidence and an event log with an expected policy.

Microsoft’s official boot-process documentation describes this separation: Secure Boot checks the bootloader, Trusted Boot continues verification into the operating system, and Measured Boot records startup evidence for remote assessment.

Measurement does not automatically declare a device healthy. The remote service needs a fresh challenge, a trusted device identity, an interpretable event log, known-good reference values, and policy for legitimate updates. A hash can prove that something changed without explaining whether the change was authorized.

NIST adds protection, detection, and recovery

NIST SP 800-193 organizes platform firmware resilience around three principles. Protection keeps firmware code and critical data from unauthorized modification. Detection identifies corruption. Recovery restores code and data to integrity after corruption is found or an authorized recovery is requested.

These functions need roots of trust that ordinary host software cannot rewrite. Update verification, write protection, integrity measurements, and recovery decisions are weak if an already-compromised operating system can silently replace their policies.

The design parallels modern software build provenance. Both systems need authenticated origins and tamper evidence, but device resilience adds a physical availability requirement: the platform must still be able to return to service.

A recovery image must be protected too

Recovery is not merely a second copy of the same firmware in writable storage. A useful recovery path needs an authenticated image, protected metadata, an independent way to trigger restoration, and enough power-failure tolerance to avoid corrupting both active and backup copies.

Rollback control is equally important. A perfectly signed old image may contain a publicly known vulnerability. A security version counter or equivalent policy can prevent restoration below an approved minimum, while a deliberate service procedure can handle exceptional repair cases.

Recovery also needs testing. A feature that has never survived an interrupted update, damaged flash region, or lost configuration should not be treated as operational resilience. Vendors should state which components can recover automatically, which require removable media or service tools, and which failures require board replacement.

Secure startup does not secure runtime

Once authorized code starts, vulnerabilities in the operating system, drivers, management firmware, applications, or network services can still be exploited. Secure Boot is not antivirus, memory isolation, access control, or patch management.

Some peripherals initialize through option ROMs or run their own firmware. Storage controllers, network adapters, graphics devices, embedded controllers, and management processors may have separate update and verification chains. Procurement claims should name the protected components rather than using “firmware” as if it were one file.

An inventory such as an SBOM can help identify affected software, but it does not enforce boot policy or restore a corrupted flash device. Inventory, verification, detection, and recovery solve different parts of the problem.

How to evaluate a device or fleet

For an individual PC, confirm that Secure Boot is enabled, firmware updates come from the manufacturer, and recovery keys or media are stored appropriately. Do not disable Secure Boot as a routine troubleshooting step; systems that need custom operating systems can often enroll an owner-controlled key instead.

For fleet purchases, ask which firmware regions and devices are authenticated, how revocation updates are delivered, whether rollback is blocked, what measurements are available, how attestation policy handles updates, and what happens after an interrupted flash. Request a documented support period and a recovery demonstration for representative failures.

Administrators should also monitor firmware versions and configuration drift. A green Secure Boot status on one day does not prove that keys, revocation lists, or peripheral firmware will remain current for the life of the machine.

Limitations and tradeoffs

Strict allow lists can complicate repair, alternative operating systems, accessibility tools, and older hardware. Broad trust databases improve compatibility but enlarge the set of accepted code. Automatic recovery improves availability but can conceal repeated faults unless events are logged and investigated.

Remote attestation can support device access decisions, yet it introduces privacy, identity, availability, and policy-management questions. A verifier that rejects every unfamiliar measurement can lock out legitimate updates; one that accepts everything provides little security.

What to watch next

The practical advances will be narrower default trust stores, dependable revocation, broader coverage of device firmware, transparent security-version policies, standardized attestation evidence, and recovery mechanisms that work after real failures. Update support duration will matter as much as the badge printed on a new product.

Secure Boot remains a valuable first gate. Firmware resilience is the complete system around that gate: deciding what may start, noticing when integrity is lost, and restoring the platform without trusting the component that may already be compromised.

Primary and authoritative sources

• NIST SP 800-193: Platform Firmware Resiliency Guidelines
• NIST SP 800-147: BIOS Protection Guidelines
• UEFI Forum: UEFI specifications
• Microsoft Learn: Secure the Windows boot process

The Domain Name System turns names such as example.com into the records that computers use to find services. That translation is critical, but ordinary DNS was not designed to prove that every answer came from the zone that published it. A forged or corrupted response can direct a user toward the wrong destination before a browser has a chance to make a secure connection.

DNS Security Extensions, or DNSSEC, add digital signatures to DNS data so a validating resolver can detect unauthorized changes. This is a valuable layer of internet infrastructure, but its scope is easy to misunderstand. DNSSEC authenticates DNS records. It does not encrypt queries, certify that a website is honest, or protect the rest of a connection by itself.

DNSSEC signs record sets, not individual users

A DNS zone publishes records in groups called resource record sets. DNSSEC adds signatures, public keys, and delegation information that allow a resolver to verify those sets. The zone operator keeps a private signing key; resolvers use the corresponding public data to check that a signed answer has not been altered since it was published.

The IETF’s DNSSEC overview and Best Current Practice describes origin authentication of DNS data as the protocol’s central purpose. A valid signature means the response is consistent with what the signer authorized. It does not mean the address is benign, the organization is trustworthy, or the application behind that address is secure.

This distinction resembles other provenance systems. Authentication can establish where data came from and whether it changed; judgment about the data still belongs to the relying system and its users.

The chain of trust starts from an assumed anchor

Internet DNS is hierarchical. A validating resolver usually begins with a trusted key for the root zone. The root signs information that points toward a top-level domain, the top-level domain authenticates a delegation to a child zone, and the child signs its own records. Delegation Signer records connect one level to the next.

The original DNSSEC introduction in RFC 4033 explains that a resolver builds an authentication chain back to a configured trust anchor. If every required link validates, an answer can be treated as secure. If a signed chain should validate but a signature is wrong, missing, expired, or unsupported, the result can be bogus and the resolver should not quietly return it as trustworthy.

A domain can also be intentionally unsigned. In that case the resolver may reach a provably insecure delegation rather than a broken signed chain. Secure, insecure, and bogus are different states; treating all validation failures as equivalent can create either outages or unsafe bypasses.

DNSSEC and encrypted DNS solve different problems

DNSSEC signatures are normally visible in DNS responses. They provide authenticity and integrity, not confidentiality. An observer may still learn which name a device is looking up, and an intermediary can still see metadata around the exchange.

Protocols such as DNS over HTTPS, DNS over TLS, and DNS over QUIC encrypt transport between a client and a resolver. They can prevent local observers from reading or modifying that part of the conversation, but the selected resolver still sees the request. Our guide to encrypted DNS and its privacy limits explains that relationship in detail.

A robust deployment can use both: encrypted transport to a chosen validating resolver, and DNSSEC validation from that resolver toward signed authoritative data. Neither mechanism replaces HTTPS or another secure application protocol after the address has been found.

A signed destination can still be dangerous

A malicious site owner can correctly sign DNS records for a malicious domain. DNSSEC will faithfully authenticate those records because they are exactly what the zone owner published. The protocol does not inspect a webpage, detect fraud, scan software, or decide whether a service deserves trust.

TLS certificates answer another question: whether the server can prove control of an identity covered by the certificate and establish an encrypted connection under the certificate ecosystem’s rules. Our article on Certificate Transparency shows that even certificate monitoring is visibility rather than a universal safety verdict.

Routing is separate again. A DNS answer can be authentic while network traffic is sent along an unexpected route. RPKI route-origin validation addresses part of the Border Gateway Protocol problem, not DNS record integrity. Internet security works in layers because no single control sees the entire path.

Signing a zone creates an operational system

A domain operator must generate and protect keys, sign records, publish the correct DNSKEY data, place the correct DS record with the parent, refresh signatures before they expire, and rotate keys without breaking the chain. Changes must propagate through caches in the right order.

A stale DS record at the parent can make a correctly configured child appear bogus. Removing old keys too early can break validation for resolvers that still have cached data. Clock errors can also matter because signatures have validity periods. DNSSEC therefore needs monitoring from outside the authoritative service, not just a configuration checkbox in a registrar panel.

Managed DNS services can automate much of this work, but responsibility still needs to be clear when a domain changes registrar, DNS provider, or ownership. Recovery procedures should be tested before an emergency migration.

Validation happens at the resolver

Most consumer devices send queries to a recursive resolver run by an internet provider, operating system, enterprise, or public DNS service. If that resolver validates DNSSEC, it performs the signature and chain checks on the user’s behalf. A browser or application may receive only the final result, so the user interface often provides little evidence that validation occurred.

Organizations running their own resolvers should monitor validation failures, software versions, supported algorithms, time synchronization, trust-anchor state, and exception mechanisms. Temporary workarounds called negative trust anchors can restore access when a signed zone is broken, but they deliberately suspend validation for a limited scope and require disciplined review.

The 2026 root key rollover tests operational readiness

The root Key Signing Key is the common trust anchor used by many validating resolvers. IANA’s current trust-anchor and rollover schedule says the successor key was introduced in January 2025 and is scheduled to begin signing the root zone on October 11, 2026. The current key will no longer sign the zone at that point.

Modern resolvers can learn a new trust anchor automatically, and vendors may distribute updates through software packages. Systems that are old, isolated, incorrectly configured, or unable to update still need attention. Operators should follow vendor instructions and verify that the current IANA trust-anchor data is available rather than waiting for the rollover date.

The rollover is not a reason for ordinary users to change domain settings. It is an infrastructure maintenance event that demonstrates why cryptographic trust depends on procedures, software updates, monitoring, and recovery as much as on algorithms.

How to evaluate a DNSSEC deployment

Domain owners should confirm that the zone is signed, the parent contains the intended DS record, the full chain validates from multiple networks, signatures have adequate time remaining, and key rollovers are rehearsed. Monitoring should distinguish an unsigned answer from a broken signed one and alert before signatures expire.

Resolver operators should test secure, insecure, and deliberately bogus domains; keep trust anchors and software current; observe validation latency and failure rates; and document any bypass. Consumers can choose a resolver that states it performs DNSSEC validation, while remembering that this choice also has privacy and policy implications.

What to watch next

The near-term milestone is a smooth October 2026 root key rollover. Longer-term progress depends on easier registrar automation, safer multi-provider DNS, modern algorithm support, better failure diagnostics, and wider validation without fragile manual steps.

DNSSEC is valuable precisely because its job is narrow and testable: it lets a resolver detect whether signed DNS data is authentic. Treating it as one verified link in a layered security system makes it more useful than presenting it as a universal badge of website safety.

Primary and authoritative sources

• IETF RFC 9364: DNS Security Extensions
• IETF RFC 4033: DNS Security Introduction and Requirements
• ICANN: DNSSEC Overview
• IANA: DNSSEC Trust Anchors and Rollovers

The padlock in a browser says that a connection is encrypted and that the website presented a certificate trusted for its domain. It does not mean the certificate authority, or CA, could never issue the wrong certificate. Certificate Transparency adds a public record to this system so that suspicious issuance can be discovered and investigated.

That is a meaningful improvement, but the word “transparency” describes the mechanism precisely. CT makes publicly trusted TLS certificates visible in auditable logs. It does not inspect a website for malware, prove that the domain owner is honest, or automatically stop every mistaken or fraudulent certificate before it can be used.

Why the web needs more than a list of trusted authorities

Browsers and operating systems maintain root stores containing certificate authorities they trust. A publicly trusted CA can issue certificates that browsers accept for many domains after completing required validation. This model allows websites to choose among providers, but it also means a failure at one trusted CA can affect users far beyond that company’s own customers.

Before transparency logs, a domain owner might not know that another CA had issued a certificate for its name. Discovery could depend on seeing the certificate in an attack, receiving a report, or finding it through external scanning. CT changes that visibility problem by creating public evidence of issuance across the Web PKI, the collection of authorities, policies, certificates, browsers, and software that supports HTTPS.

An append-only log creates evidence, not approval

RFC 9162 describes Certificate Transparency version 2 as a protocol for publicly logging TLS server certificates so that CA activity and the logs themselves can be audited. A certificate or precertificate is submitted to one or more logs. Each log returns a signed certificate timestamp, or SCT, promising to include the entry within a defined period.

The log organizes entries with a Merkle tree, a cryptographic structure that produces a compact root hash. Inclusion proofs can show that a particular certificate is present. Consistency proofs can show that a newer tree extends an older one without quietly rewriting history. Monitors can download entries, watch for names they care about, and compare signed tree states.

None of those steps says the certificate was correctly authorized. A log normally records evidence rather than deciding whether issuance was legitimate. That separation lets independent monitors investigate the same public history, but it also means a misissued certificate can appear in a perfectly functioning log.

Browsers turn logging into an ecosystem requirement

Transparency becomes effective when clients demand proof that a certificate was logged. Chrome’s current CT policy evaluates SCTs during certificate validation and requires publicly trusted TLS certificates to be CT compliant. The policy considers the certificate lifetime, the number of SCTs, the status of the logs, and whether evidence comes from distinct log operators.

This policy pressure makes undisclosed public issuance difficult to use in compliant browsers. It also avoids relying on one log: multiple independent records reduce the impact of a single unavailable or dishonest operator. Chrome publishes log lists and defines states such as usable, read-only, retired, and rejected so clients can respond when a log’s operating status changes.

Private enterprise certificate authorities are a different case. A locally installed CA is not automatically part of the public CT ecosystem, and internal names may be inappropriate for a public log. Organizations therefore need separate inventory and monitoring for private PKI rather than assuming browser CT covers every certificate in their environment.

Detection still depends on monitoring

Publishing millions of certificates does not help a domain owner unless someone examines the stream. A useful monitor normalizes domain names, recognizes wildcard coverage, tracks expected issuers, and alerts on an unfamiliar certificate quickly enough for investigation. Large organizations also need ownership data so an alert reaches the team responsible for the affected domain.

An unexpected record is not automatically an attack. A cloud service, content delivery network, hosting provider, or forgotten business unit may have requested it legitimately. Conversely, a familiar CA name does not prove authorization. Response teams must compare the entry with change records, validation history, DNS control, account activity, and the certificate’s actual use.

This resembles the visibility limits discussed in our article on encrypted DNS. A protocol can protect or expose one part of the path without answering every security question around it.

What happens after suspicious issuance is found

The domain owner and CA need to determine how validation succeeded, revoke the certificate when appropriate, protect the affected account or DNS path, and notify browser root programs if policy violations are involved. Revocation has its own delivery and reliability constraints, so short certificate lifetimes and browser enforcement policies also limit exposure.

The CA/Browser Forum Baseline Requirements define widely used rules for issuing and managing publicly trusted TLS server certificates. CT complements those issuance rules by making the resulting certificates inspectable. It does not replace domain validation, audits, incident reporting, revocation, or root-store governance.

A similar distinction appears in RPKI for internet routing: cryptographic authorization can address a specific failure while routing operations and incident response remain necessary.

The logs themselves need scrutiny

A transparency system must resist split views, in which different observers receive inconsistent versions of history. Signed tree heads and consistency proofs make such behavior detectable, but detection benefits from monitors and witnesses that exchange observations. Availability also matters because CAs need usable logs to issue compliant certificates and clients need current policy information.

Log operators face scale, retention, reliability, and governance requirements. Browser programs can retire or reject logs that no longer satisfy policy. Diversity of operators is therefore a security property as well as an availability choice. A public ledger is more credible when no single organization controls all accepted views of it.

Transparency also exposes certificate names

Public logging means certificate contents, including domain names, become searchable. For normal public websites that information is often already discoverable, but an organization can accidentally reveal a descriptive subdomain for a service that was not meant to be advertised. CT is not the right place for private internal names.

Security teams should treat CT data as both a defensive feed and a reminder to manage naming. Alerts can identify unauthorized issuance, unexpected third-party services, abandoned domains, and certificate automation that has drifted from policy. They should not be used as the only asset inventory because systems without public certificates will be absent.

What Certificate Transparency cannot tell users

A logged certificate can still belong to a phishing domain with a look-alike name. It can protect an encrypted connection to a malicious service. CT does not assess website content, software integrity, privacy practices, or the owner’s intentions. It also does not prove that a server’s private key has remained secret.

Nor does a clean monitor result prove that no attack occurred. Coverage depends on which names are watched, alert latency, matching logic, and whether the relevant connection uses the public trust system. CT evidence should join DNS monitoring, account protection, key management, vulnerability response, and software provenance. As with build provenance, traceability is valuable without being a verdict on safety.

What to watch next

The most useful progress will improve independent verification and response speed: broader monitoring, interoperable witnesses, reliable log diversity, clearer incident handling, and certificate automation that connects an unexpected issuance directly to an accountable owner. Site operators should also watch browser root-program changes because client policy determines which SCT combinations and logs are accepted.

Certificate Transparency changed the Web PKI by making secret public issuance much harder to hide. Its strength is accountability after a cryptographic event has been recorded. The right expectation is not that CT makes misissuance impossible, but that it creates evidence, enables detection, and raises the cost of keeping a bad certificate unnoticed.

Primary and authoritative sources

• IETF RFC 9162: Certificate Transparency Version 2.0
• Chrome Certificate Transparency Policy
• Certificate Transparency in Chrome
• CA/Browser Forum Baseline Requirements for TLS Server Certificates

When a device opens a website or connects to an online service, the Domain Name System translates a human-readable name into network information. Traditional DNS traffic is often unencrypted, allowing a network operator or nearby observer to see or modify queries between a device and its resolver.

DNS over HTTPS, DNS over TLS, and DNS over QUIC protect queries in transit to a recursive resolver. That is meaningful privacy and security, but it is not anonymity, domain validation, malware protection, or end-to-end encryption of every lookup stage.

A DNS lookup involves several roles

A phone or computer usually sends a query through a small local component called a stub resolver. The query goes to a recursive resolver operated by an internet provider, enterprise, device vendor, or independent service. If the answer is not cached, that resolver may contact root, top-level-domain, and authoritative name servers to assemble the result.

The recursive resolver sees requests from the client and returns answers. Authoritative servers publish information for particular domains. Encryption between the client and recursive resolver protects one important connection, but the resolver remains a powerful observation and policy point.

Ordinary DNS exposes useful metadata

Unencrypted DNS can reveal which domain names a device requests, when it requests them, and how often. A domain is not necessarily the same as a specific page, yet it can still disclose interests, applications, services, and activity patterns. An attacker on the path may also attempt to inject a false answer or redirect a query.

An exposed DNS lookup remains a separate source of metadata even when web traffic uses HTTPS. Encrypted DNS complements encrypted application traffic; it does not replace it.

DoH, DoT, and DoQ protect the transport

DNS over HTTPS, standardized in RFC 8484, carries DNS messages inside HTTPS. DNS over TLS uses a dedicated TLS-protected connection, while DNS over QUIC uses QUIC’s encrypted transport. All three aim to provide confidentiality and integrity between a client and the chosen recursive resolver.

That protection can prevent passive observers on the local network from reading the query and make active modification on that path much harder when server authentication is performed correctly. The protocols differ in transport behavior, ports, deployment, and how easily network administrators can identify or manage them, but their privacy boundary is similar.

The recursive resolver still sees the query

Encryption moves trust; it does not remove trust. The resolver must process the requested domain and can usually associate it with a client address or account context. RFC 9076 notes that encrypting the connection does not reduce the information available to the recursive resolver itself.

Resolver policy therefore matters. Users and organizations should examine retention, logging, jurisdiction, security controls, incident history, business model, and whether queries are combined with other data. Concentrating large numbers of users on a few public resolvers can reduce exposure to local networks while increasing the importance of those providers.

DNSSEC answers a different question

DNS Security Extensions allow a resolver to validate cryptographic signatures associated with DNS data. DNSSEC can provide origin authentication and integrity for signed records, helping detect tampering between authoritative publication and validation. It does not normally hide the query from observers.

Encrypted DNS and DNSSEC are therefore complementary. Transport encryption protects the client-to-resolver conversation. DNSSEC validation helps the resolver determine whether signed data is authentic. A secure deployment may use both rather than treating either acronym as a complete replacement for the other.

Protective DNS adds another layer

A protective DNS service can block or redirect queries associated with known malware, phishing, command-and-control infrastructure, or policy violations. NIST’s 2026 DNS security guidance treats encrypted DNS, DNSSEC, protective DNS, monitoring, and logging as parts of defense in depth.

Filtering depends on threat intelligence, classification speed, and policy. It can miss new infrastructure or block a legitimate domain by mistake. Encryption to an approved resolver can protect queries while preserving defensive controls; encryption to an application-selected resolver can bypass them.

Application-controlled DNS creates a policy tension

A browser or app may select its own resolver rather than use the operating system or enterprise network setting. This can improve privacy on an untrusted network. In a managed organization, however, it may bypass internal domain resolution, parental controls, incident monitoring, or a protective DNS service.

Administrators can define approved resolvers, distribute encrypted-DNS settings, provide local discovery, and monitor endpoint configuration. This fits zero trust security: make policy explicit and verify the path instead of assuming an internal request is safe.

Encrypted DNS does not hide all connection metadata

After receiving an address, a device still connects to a destination. IP addresses, traffic timing, volume, and routing can reveal information even when the DNS exchange is encrypted. Other protocol fields may also expose a service name unless the relevant application and transport protections are deployed.

A resolver can also correlate multiple queries over time. Encrypted DNS should be evaluated as one privacy control inside a broader system, not as a tool that makes browsing invisible to providers, employers, websites, or network infrastructure.

Oblivious DoH separates identity from query content

Oblivious DNS over HTTPS, described in experimental RFC 9230, inserts a proxy between the client and target resolver. The client encrypts the DNS message for the target. The proxy can see the client’s network address but not the plaintext query, while the target can decrypt the query but receives it from the proxy.

This separation aims to prevent one service from seeing both identity and query content. It introduces additional dependencies, latency, operational complexity, and collusion assumptions. It is a useful privacy design, not a universal feature of ordinary DoH.

Availability and performance still matter

Resolvers cache answers, select upstream paths, enforce timeouts, and protect themselves from attacks. Latency depends on geography, cache state, transport setup, congestion, and capacity. An unreliable resolver can make many applications appear broken.

Encrypted connections add state and cryptographic work, although modern implementations can reuse sessions and multiplex requests. Organizations should test failover and captive-portal behavior. They should also avoid configurations that silently fall back to unencrypted DNS without making that policy clear.

Logging can support defense and create privacy risk

DNS logs help investigators identify infected devices, trace phishing activity, and understand outages. The same logs can reveal sensitive behavior. A responsible program defines what is collected, who can access it, how it is protected, and when it is deleted.

This balance also applies at home. Smart devices may contact many services without a visible browser, making DNS useful for troubleshooting and security. The practical controls in our smart-home security checklist remain relevant: update devices, segment where possible, and review unexpected communication rather than relying on one network feature.

Deployment should begin with a threat model

A traveler using public Wi-Fi, a household using a trusted filtering resolver, and a regulated enterprise have different requirements. Consumers should enable a reputable encrypted resolver through the operating system, router, or browser and check whether all applications follow that setting. Organizations should inventory DNS paths before setting policy.

Security teams should validate DNSSEC where appropriate, use protective DNS based on risk, retain only justified logs, and keep a tested recovery path. Routing security also matters outside DNS; technologies such as RPKI route-origin validation address a different layer of internet trust.

Limitations

Protocol support varies across operating systems, applications, routers, and networks. A settings label may not reveal which resolver is used, whether fallback occurs, or whether every application follows the system configuration. VPN software, enterprise agents, and security products can alter the path.

Privacy claims also depend on implementation and provider behavior. Encryption cannot prevent a resolver from retaining data it legitimately receives, and it does not guarantee that an answer is safe. Published policies, independent audits, open standards, and transparent incident handling offer stronger evidence than a privacy-themed product name.

What to watch next

Watch for wider support for encrypted resolver discovery, clearer operating-system controls, stronger default authentication, privacy-preserving relay designs, and enterprise tools that preserve both encryption and accountable policy. Adoption of DNSSEC validation and better measurement of fallback behavior remain important.

Encrypted DNS is valuable because it protects a previously exposed part of everyday networking. Its real strength becomes clearer, not weaker, when users understand exactly where that protection ends.

Sources: NIST SP 800-81 Revision 3, Secure Domain Name System Deployment Guide; IETF RFC 8484, DNS Queries over HTTPS; IETF RFC 9076, DNS Privacy Considerations; IETF RFC 9230, Oblivious DNS over HTTPS.

Downloading software usually requires trusting that the file came from the project it claims to represent. A source repository may be public, yet the executable, container image, or package that reaches a user was produced by a separate build system. If that system or distribution path is compromised, clean source code can still become a malicious release.

Build provenance is meant to narrow that gap. It records how a software artifact was produced, including the build platform, external parameters, and important inputs. When the record is generated and authenticated by trustworthy infrastructure, a consumer can verify that an artifact followed an expected path. That is valuable evidence, but it is not proof that the software has no vulnerabilities.

Source code and released software are different artifacts

A repository commit is an input. A compiled binary or packaged container is an output. Between them sit compilers, dependencies, scripts, environment variables, caches, credentials, and publishing systems. An attacker may target any of those steps rather than editing the visible source.

A release process should therefore identify the exact immutable source revision and the exact output digest. A cryptographic digest acts like a fingerprint for the bytes. If one byte changes, the digest changes. Provenance connects that output to a declared build process so a verifier can compare what happened with what should have happened.

Provenance is a claim, while an attestation authenticates it

SLSA, the Supply-chain Levels for Software Artifacts framework, defines provenance as metadata describing how outputs were produced. An attestation is an authenticated statement about an artifact. The distinction matters because anyone can write a text file claiming that a package came from a secure builder.

A signed attestation lets a verifier check who issued the claim and whether it was altered. The verifier still needs a policy that decides which issuers, repositories, workflows, and parameters are acceptable. A valid signature answers who made the statement; it does not make every statement trustworthy.

SLSA levels describe increasing build assurance

The current SLSA build track provides progressive levels. At Build L1, provenance exists and documents the build, but the record can still be easy to forge. Higher levels require provenance generated by a hosted build platform and increasingly hardened build infrastructure. The goal is to make tampering with the artifact, record, or build environment more difficult.

Levels are useful as a common language, not a security score for the application itself. A project can use a strong isolated builder to produce flawed code perfectly. Conversely, a small project may write careful code while lacking mature attestation infrastructure.

Verification is the step that creates protection

Collecting attestations without checking them produces an archive, not a control. A package registry, deployment pipeline, or acquiring organization needs to verify the signature, artifact digest, builder identity, source repository, and approved workflow before accepting a release.

Policies should fail safely. If provenance is missing or does not match expectations, the system should block or quarantine the artifact instead of silently continuing. Exceptions need an owner, reason, expiration, and audit trail. This turns provenance into an enforceable boundary rather than a decorative badge.

What provenance can help detect

Build records can expose a release compiled from the wrong commit, an artifact published outside the official workflow, or a package whose digest changed after signing. A hardened builder can reduce opportunities for one build to influence another or steal signing material. Detailed inputs also help responders determine which releases used a compromised tool or dependency.

That last function complements an software bill of materials. An SBOM describes components in a release. Provenance describes how the release was built. Organizations often need both to investigate supply-chain risk.

What provenance does not prove

A correctly traced program may contain memory corruption, weak authentication, unsafe defaults, or deliberately harmful behavior approved in its source. Provenance also cannot prove that a dependency is benign merely because its identity is known. It supports integrity and traceability, not a complete judgment of software quality.

Secure development still requires threat modeling, code review, testing, vulnerability response, and design choices such as the use of memory-safe languages where appropriate. NIST’s Secure Software Development Framework treats provenance as one practice within a broader lifecycle.

The build platform becomes a critical trust anchor

If the control plane that creates attestations is compromised, it may issue convincing records for malicious outputs. Build services need strong administrator controls, isolated jobs, protected signing identities, minimal secrets, patched runners, and reliable logs. Short-lived credentials and workload identity can reduce reliance on long-lived signing keys stored in configuration.

Dependencies fetched during a build also need controls. Pinning immutable versions and verifying their digests helps prevent a package name from resolving to different bytes later. Build caches should not let one tenant poison another tenant’s result.

Reproducible builds add a separate kind of evidence

A reproducible build produces the same output bytes when independent parties use the same declared inputs and process. This can reveal hidden or undocumented changes between source and binary. It is powerful, but difficult when timestamps, random values, network downloads, or platform-specific behavior influence output.

Reproducibility and signed provenance solve related but different problems. Provenance states how one build occurred; reproduction tests whether that statement leads to the same result elsewhere. Strong supply-chain assurance can use both.

What software buyers should request

Organizations can ask suppliers which artifacts receive provenance, who operates the builder, how identities are protected, whether verification occurs before release, and how long records remain available. They should test whether a product update can be linked to an approved source revision and whether emergency releases follow controlled procedures.

Regulatory vulnerability-reporting duties, including those discussed in our coverage of the EU Cyber Resilience Act, become easier to manage when producers can trace affected builds precisely.

Limitations

Build provenance formats and ecosystem support are still uneven. Verification policies can be complex across many programming languages and registries. A strong attestation chain may stop at a third-party dependency that provides little evidence. Smaller projects may also face operational costs when adopting hosted, hardened builds.

Security levels should not be compared across products without checking scope. A claim may cover one package, one workflow, or only recent releases rather than the entire product.

What to watch next

Watch for package managers and deployment systems to verify attestations by default, for more dependencies to publish interoperable provenance, and for procurement rules to ask for machine-checkable evidence rather than questionnaires. Transparent incident reports should show whether provenance actually detected or limited a compromise.

Build provenance cannot tell users that software is safe. It can tell them whether the software in front of them was produced through the process they agreed to trust.

Sources: SLSA Build Terminology; SLSA Build Levels; NIST Secure Software Development Framework; CISA software supply-chain guidance for customers.

Passkeys are one of the strongest practical replacements for passwords. They use public-key cryptography, work with the screen lock already protecting a phone or computer, and are designed to resist phishing. A fake login page cannot simply collect a passkey and replay it on the real site the way it can steal a password or a one-time code.

That does not make the entire account secure. The strongest sign-in method can be undermined by a weak recovery path. If a service lets an attacker reset a passkey with an easily hijacked email account, an SMS code, or personal information, the attacker may bypass the passkey instead of breaking it. Passkey adoption therefore shifts part of the security problem from remembering secrets to managing devices, provider accounts, and recovery.

How a passkey differs from a password

A password is a shared secret. The user knows it, and the service stores information that lets it verify the same secret. That creates several familiar risks: people reuse passwords, attackers steal password databases, and fake sites can trick users into typing credentials.

A passkey uses a cryptographic key pair. The service keeps the public key, while the private key stays with the user’s authenticator, such as a phone, computer, password manager, or hardware security key. During sign-in, the service sends a challenge and the authenticator signs it. The private key is not sent to the website. A fingerprint, face check, or device PIN usually unlocks local use of the credential; according to the FIDO Alliance, biometric data remains on the device rather than being sent to the remote service.

Why passkeys resist phishing

NIST’s current digital identity guidance describes phishing resistance as an authentication protocol preventing useful secrets or authenticator outputs from being disclosed to an impostor verifier. WebAuthn, the browser standard used by passkeys, binds a credential to the relying party’s domain. A passkey created for one legitimate domain will not authenticate a lookalike domain controlled by an attacker.

This protection does not depend on a user noticing a slightly misspelled address. The protocol enforces the boundary. NIST also notes that passwords are not phishing-resistant, and manually entered one-time codes are not considered phishing-resistant because an attacker can relay them to the real service.

Synced and device-bound passkeys solve different problems

A synced passkey can be made available across a user’s devices through a passkey provider. That improves convenience and reduces the risk of losing access when a phone breaks. A device-bound passkey remains on one authenticator, such as a hardware security key or a managed enterprise device. It can offer stronger control over where the private key exists, but it requires more deliberate backup and replacement planning.

Neither model is automatically right for every account. A consumer service may prioritize easy recovery and cross-device use. A high-assurance enterprise may require managed, device-bound credentials. The important point is for the service to know what assurance it needs and for the user to understand where credentials are stored.

Recovery is the real stress test

People lose phones, replace laptops, switch platforms, forget provider-account credentials, and sometimes lose access to every registered device. A service needs a recovery process, but that process should not quietly become a weaker second login system. Attackers frequently target customer support, mobile-number transfers, and email resets precisely because primary authentication is harder to defeat.

A robust design can allow several recovery options without relying on one fragile channel. Users might register passkeys on more than one device, keep a hardware security key in a safe place, or store single-use recovery codes offline. A service can add waiting periods, notifications to existing devices, risk checks, and stronger identity verification for unusual recovery attempts. Recovery should also create a clear audit trail and revoke credentials that may have been lost.

What services need to implement

Adding a “create passkey” button is only the visible part of the work. Services need credential-management pages that show when passkeys were created, let users name and remove them, and explain what will happen on a new device. They should support more than one passkey per account and avoid forcing users back to a password for routine device changes.

Fallback methods need the same scrutiny as the primary method. An account protected by a passkey but recoverable through a weak security question is not meaningfully passwordless. This is similar to the system-boundary problem described in AI Agent Protocols Are Becoming Infrastructure, but Not a Trust System: a strong protocol does not secure every connected component.

What users can do now

When a service supports passkeys, create more than one recovery route before an emergency. Keep at least two trusted devices or add a hardware security key for important accounts. Protect the passkey provider account with strong authentication, review its recovery email and phone number, and remove old devices that are no longer controlled.

Users should also keep device security current. Passkeys do not protect an account from malware that controls an already unlocked device or from a stolen authenticated session. Software updates, full-disk encryption, a strong device PIN, and remote-device removal still matter. The broader software risks discussed in Memory-Safe Languages Are Becoming a Cybersecurity Requirement do not disappear when passwords do.

Limitations and remaining attack paths

Passkeys reduce credential phishing and password reuse, but they do not verify that a transaction is wise. A scammer may persuade an authenticated user to transfer money or disclose information. Malware may abuse a logged-in session. A compromised service can still expose personal data even if it cannot leak reusable password hashes.

Organizations also need to monitor enrollment and recovery as part of their exposure-management program. A sudden new passkey, recovery from an unusual location, or removal of every older credential can be a security signal. This operational view fits the continuous approach described in CTEM Turns Vulnerability Management Into Continuous Exposure Reduction.

What to watch next

The next stage of passkey adoption will be judged by portability, recovery quality, and transparent credential management rather than sign-in demos. Watch for safer movement between passkey providers, consistent support across browsers and apps, clearer assurance information for organizations, and recovery flows that do not fall back to phishable credentials.

Passkeys solve an important problem: they remove a reusable secret from ordinary sign-in and bind authentication to the real service. That is a substantial improvement. The remaining challenge is to make the entire account lifecycle, especially recovery, as strong as the passkey itself.

Sources: NIST SP 800-63B-4: Authenticators; NIST: Authentication and Authenticator Management; FIDO Alliance: Passkeys; FIDO Alliance guidance on replacing password and OTP authentication.

Cybersecurity teams have spent years collecting vulnerability lists, scanner results, endpoint alerts, cloud findings, and compliance reports. The problem is that more findings do not automatically create less risk. Continuous threat exposure management, often shortened to CTEM, is an attempt to make the work more operational: identify what is exposed, decide what matters most, validate whether attackers can actually use it, and keep reducing exposure as systems change.

For ordinary technology enthusiasts, CTEM is useful because it explains why security is no longer a once-a-quarter audit. Modern companies run cloud services, software supply chains, remote access tools, APIs, identity systems, and connected devices that change constantly. A static checklist cannot keep up. The better question is whether an organization can see its most attractive attack paths and close the ones that matter before a real attacker does.

Why vulnerability counts are not enough

A large company can have thousands of known vulnerabilities, misconfigurations, expired assets, weak identity controls, and exposed services. Treating every issue as equally urgent creates noise. It also wastes time, because a low-severity bug on an internet-facing system with known exploitation may be more urgent than a higher-scoring issue buried inside a well-isolated lab environment.

This is where authoritative risk signals help. CISA’s Known Exploited Vulnerabilities catalog is valuable because it focuses attention on vulnerabilities that have been exploited in the wild. NIST’s Cybersecurity Framework 2.0 gives organizations a broader structure for governing, identifying, protecting, detecting, responding, and recovering. NIST’s patch management guidance also emphasizes planning and prioritization, not just installing updates as a mechanical chore.

What CTEM changes in practice

A CTEM program starts with scoping. The organization decides which business systems, cloud accounts, identities, applications, suppliers, and endpoints matter most. Then it discovers exposure: open ports, risky SaaS permissions, forgotten servers, vulnerable libraries, leaked credentials, weak remote access, shadow APIs, or gaps in endpoint coverage. The aim is not to create a perfect inventory in one heroic pass, but to keep improving the view.

Next comes prioritization. Good prioritization blends exploit evidence, asset importance, internet exposure, compensating controls, business impact, and attacker behavior. A payroll system, production database, identity provider, or customer-facing API deserves different treatment from a test machine with no sensitive access. That sounds obvious, but many teams still operate from scanner exports that do not understand business context.

Validation is the uncomfortable step

The most mature part of CTEM is validation. Instead of assuming every theoretical weakness is exploitable, teams test whether an attack path actually works. This may involve breach-and-attack simulation, controlled penetration testing, red-team exercises, configuration checks, or attack-path analysis across identity and cloud permissions. The goal is evidence.

Validation must be handled carefully. It should be authorized, logged, scoped, and designed to avoid disruption. But without some form of validation, security teams can end up patching what is easiest to measure rather than what most reduces risk. This is especially important as organizations adopt software bills of materials and inventory practices like those discussed in Software Bills of Materials Are Becoming a Security Inventory Tool. Knowing what software exists is only the start; knowing which exposure creates a real path to compromise is the next step.

Identity and cloud exposure are now central

Older vulnerability programs often focused on operating systems and application patches. Those still matter, but cloud and identity systems have changed the map. A misconfigured storage bucket, over-permissive service account, stale API key, exposed admin panel, or weak multi-factor authentication exception can be as dangerous as a classic software flaw. In some attacks, the decisive weakness is not a bug at all. It is an account, token, trust relationship, or forgotten external service.

This connects naturally to zero trust, which is best understood as a set of verification and least-privilege design principles rather than a product. Our earlier guide, Zero Trust Security for Everyday Organizations, explains why access should be continuously evaluated. CTEM provides a complementary operating rhythm: keep asking which exposures would let an attacker move from one system to another.

Limitations and common mistakes

CTEM can become another dashboard if leadership treats it as a tool purchase instead of a program. Buying a platform does not automatically create asset ownership, remediation authority, test discipline, or executive follow-through. Teams also need to avoid over-automation. Automated scanning is essential, but it can miss business logic, supplier risk, human workflow, and unusual attack chains.

Another mistake is reporting only activity metrics. The number of vulnerabilities closed matters less than whether critical exposure is shrinking. Better measures include time to remediate known exploited vulnerabilities, percentage of critical assets covered by inventory, reduction in externally reachable risky services, validated attack paths removed, and recurring exposure trends by business unit.

What to watch next

Expect CTEM to become more closely tied to asset intelligence, cloud security posture, identity governance, and software supply-chain visibility. Expect regulators and insurers to care more about whether companies can prove they understand their exposure. Also expect attackers to keep favoring weakly governed systems: edge devices, remote access, unmanaged cloud services, and third-party software. That is why route-security work such as RPKI and BGP Route Origin Security belongs in the broader exposure conversation, even though it looks like a networking topic.

The practical takeaway is simple. Security teams do not need more endless lists. They need a repeatable way to find, rank, validate, and reduce the exposures that attackers are most likely to use. CTEM is not magic, but it gives vulnerability management a clearer job: make the organization harder to attack this month than it was last month.

Sources: CISA Known Exploited Vulnerabilities catalog; NIST Cybersecurity Framework 2.0; NIST SP 800-40 Rev. 4 patch management guidance.