CISA made Log4Shell repair a proof problem, not a patch slogan

Summary

Log4Shell turned a Java logging component into a global accountability test because many organizations could not quickly tell whether Apache Log4j was present directly, embedded in products, bundled inside appliances, or hidden in vendor-managed services.
CISA's public guidance and Emergency Directive 22-02 made the repair problem visible: patching was not a slogan. Covered federal civilian agencies had to identify affected assets, mitigate or update, report status, and keep looking as products and guidance changed.
The central accountability issue is verifiable repair. A public statement that "we patched" does not prove inventory completeness, nested dependency discovery, compensating controls, vendor coordination, exploitation monitoring, or closure evidence.
Responsibility was distributed. Apache maintained the project and fixed releases. Agencies and enterprises controlled asset discovery. Vendors controlled product advisories. Cloud and security providers observed exploitation and blocking. Customers needed evidence that their suppliers had actually reduced exposure.
The durable lesson is that software supply-chain governance fails when organizations cannot prove what they run. Log4Shell made inventory, SBOMs, vulnerability management, and post-patch monitoring operational necessities rather than compliance paperwork.

The emergency was an inventory failure as much as a code flaw

The Log4Shell story begins with a vulnerability, but the accountability story begins with discovery. Apache's Log4j security page and the entry for CVE-2021-44228 describe the project-level facts: affected versions, fixed versions, related vulnerabilities, and mitigation context. NVD's CVE-2021-44228 record provides the public vulnerability metadata and severity framing. Those sources establish why the vulnerability was urgent. They do not establish whether any particular organization found every copy of Log4j it was running.

That distinction defined the crisis. Many organizations knew they had Java applications. Fewer knew which internal services, vendor products, appliances, development tools, and cloud workloads embedded Log4j. The component could sit inside applications that no longer had active owners. It could be bundled into products under a vendor's name rather than Apache's. It could exist in test environments, older releases, admin consoles, logging collectors, or third-party software. A team could patch the obvious server and still leave an exposed product elsewhere.

CISA's first Apache Log4j vulnerability guidance alert captured the public urgency. The agency's broader Apache Log4j Vulnerability Guidance resource collected operational references. But the deeper contribution was not merely publishing another advisory. CISA helped turn the conversation from "there is a critical CVE" to "show your work." The question became which systems had been checked, which systems were vulnerable, which had been patched, which had compensating controls, and which were waiting on vendors.

This is where the word "patch" became too small. Patching an internally owned application is one act. Finding embedded Log4j inside a vendor appliance is another. Applying a mitigation because a fixed version is not yet available is another. Checking logs for exploitation is another. Retesting after a vendor revises guidance is another. Removing old vulnerable libraries from a build is another. The public needed a vocabulary that could separate those acts.

The accountable question after Log4Shell was not "Did you patch?" It was "Can you prove the vulnerable component is no longer exploitable in the systems you control, and can you prove what remains uncertain?" An organization that could answer that question had an inventory and evidence base. An organization that could not had a governance problem even if its engineers worked through the weekend.

Emergency Directive 22-02 made repair measurable for covered agencies

CISA's Emergency Directive 22-02 applied to U.S. Federal Civilian Executive Branch agencies. That scope matters. The directive did not create obligations for every private company on earth, and a responsible public article should not imply that it did. Its importance lies in the repair model it made visible: identify affected assets, mitigate, report, and keep updating the status as information changed.

The directive's accountability value was procedural. It recognized that an emergency vulnerability response cannot be managed by one announcement. Covered agencies had to review internet-facing assets, use CISA-provided tools or equivalent methods, update or mitigate affected software, and report status. The directive also recognized that product lists and vulnerability knowledge would evolve. That meant agencies could not simply declare closure on day one and walk away.

This is the proof problem. If an agency said it had no affected assets, what inventory supported that statement? If it said an asset was mitigated, what control was applied and how was it tested? If a vendor product was still waiting for a patch, what compensating control reduced exposure? If a new affected product appeared later, how did the agency revisit the assessment? Repair was an evidence loop.

The same logic applied outside federal scope even when the directive did not legally bind private organizations. Enterprises, states, universities, hospitals, cloud providers, and small businesses all faced the same technical problem: find the component, understand exposure, fix or mitigate, watch for exploitation, and document remaining risk. CISA's directive gave them a public example of disciplined emergency governance.

The Known Exploited Vulnerabilities Catalog reinforces the point. When a vulnerability is known to be exploited, vulnerability management is no longer a theoretical ranking exercise. It becomes an operational duty. The catalog does not prove which organization was exploited. It tells defenders that active exploitation is a governance input. For Log4Shell, exploitation context made "we will patch later" a much weaker position.

Emergency directives also reveal a cost-transfer problem. Agencies and enterprises were dependent on vendors to disclose whether products embedded Log4j, provide patches, explain mitigations, and update advisories. A customer could own the risk but not the full knowledge. If a vendor's advisory was late or vague, the customer's repair record was weaker. That dependency became a public accountability issue because affected systems often supported essential services.

Vendors controlled facts customers could not independently see

Log4Shell exposed a basic asymmetry in software supply chains. Customers can scan their own systems, but they often cannot see inside proprietary products or managed cloud services. They need vendors to say whether a product is affected, which versions are vulnerable, whether a patch exists, whether a mitigation is safe, and whether exploitation was observed. Vendor advisories became evidence entities.

Apache controlled the open-source project record for Log4j itself. Product vendors controlled how that component appeared inside their own software. Cloud providers controlled managed-service posture. Security companies controlled telemetry and detection guidance. Customers controlled deployment, exposure, and local mitigation. The vulnerability traveled across all these layers. Accountability required each layer to be specific about what it knew.

This is why software bills of materials became more than a policy phrase. CISA's SBOM resources describe a way to improve visibility into software components. An SBOM alone does not patch a vulnerability. It does not prove a product is safe. But when a crisis hits, a reliable component inventory can shorten the time between "Log4j is vulnerable" and "these products, versions, and services are affected." Without that inventory, customers and vendors hunt manually under pressure.

NIST SP 800-161 Revision 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, gives the governance framing. Supply-chain risk is not only procurement paperwork. It is the reality that security outcomes depend on components and suppliers outside the buyer's direct control. Log4Shell showed the operational version of that truth. A buyer's incident-response clock started before many buyers knew which suppliers were in scope.

The CISA Secure by Design guidance adds a supplier-duty lens. Software makers should reduce the burden they place on customers. During Log4Shell, that meant timely advisories, clear affected-version matrices, safe mitigation instructions, and later confirmation that fixes were complete. A vendor that waited, hedged, or published vague statements pushed cost onto customers who had to keep asking whether they were exposed.

The accountable vendor response had several traits. It named affected products and versions. It distinguished "not affected" from "under investigation." It identified workarounds and their risks. It updated advisories when facts changed. It explained whether exploitation had been observed in the vendor's product. It provided customers with a way to verify installed versions. It kept old advisories available for audit. Those traits turned vendor communication into usable repair evidence.

Exploitation monitoring was part of repair

Fixing a vulnerable library does not answer whether the vulnerability was exploited before the fix. Log4Shell response therefore required detection and hunting. Microsoft's guidance, Guidance for preventing, detecting, and hunting for CVE-2021-44228 exploitation, showed how defenders approached logs, indicators, and suspicious activity. Cloudflare's Inside the Log4j2 vulnerability described exploitation and mitigation observations from an edge provider's vantage point.

These sources matter because they make repair two-dimensional. One dimension is exposure: where vulnerable Log4j existed and whether it could be reached. The other is compromise: whether attackers used the vulnerability before, during, or after patching. An organization that patched every known instance but never reviewed logs might still miss an attacker who entered before the fix. An organization that hunted for exploitation but left unknown vulnerable products exposed remained at risk.

Publicly, that distinction is often lost. A company may say it remediated the vulnerability. Customers may hear that as "no incident occurred." Those are different claims. Remediation means a vulnerability was addressed. Investigation means evidence was reviewed for exploitation. Incident closure means the organization has enough facts to say what happened, what did not happen, and what remains uncertain. Log4Shell required all three.

The difficulty was that exploitation attempts were noisy and widespread. Attackers and researchers scanned the internet. Security products blocked attempts. Logs contained probes, payloads, and sometimes ambiguous strings. Some organizations had detailed logs; others did not. Some products logged the right fields; others lost evidence. Some systems were internet-facing; others were reachable only internally. The presence of a scan did not always equal compromise. The absence of a log entry did not always prove safety.

That is why proof had to be modest. A responsible organization could say: these systems were vulnerable, these were patched, these logs were reviewed over this period, these indicators were found or not found, these systems lacked sufficient historical logs, and these compensating controls remain. That statement is less tidy than "we fixed it," but it is more useful. It tells decision-makers where confidence is high and where residual uncertainty remains.

The same standard should apply to vendors. If a product vendor says a product was affected but no exploitation was observed, the customer should ask how the vendor would know. Did the product have telemetry? Did the vendor receive customer reports? Were logs available? Were exploit attempts blocked before reaching the vulnerable function? Was the statement based on absence of evidence or evidence of absence? This level of precision is not pedantry. It is how customers decide whether further action is needed.

Typography note

Typography is the art and technique of arranging type to make written language legible, readable, and visually appealing. It involves selecting typefaces, point sizes, line lengths, line-spacing, and letter-spacing.

Typography originated with the invention of movable type by Johannes Gutenberg in the 15th century.
Key elements include font selection, kerning, tracking, and leading.
Good typography enhances readability and conveys mood or tone in design.

Inventory should be treated as a live control

Log4Shell embarrassed asset inventories. Many organizations discovered that vulnerability management databases, procurement records, cloud inventories, and application-owner spreadsheets did not agree. They might know the name of a business service but not its libraries. They might know a server but not the Java package inside a container. They might know a vendor product but not the components it bundled. They might know production but not old test environments.

NIST SP 800-40 Revision 4, Guide to Enterprise Patch Management Planning, is useful because it treats patch management as a program, not a scramble. A program needs asset identification, vulnerability awareness, prioritization, testing, deployment, verification, and exception management. Log4Shell showed what happens when those steps are too slow for an emergency. The technical exploit was fast; the organizational map was often slow.

The accountable repair after Log4Shell should therefore include inventory improvement. Which systems lacked owners? Which products could not be scanned? Which vendors could not answer quickly? Which internal applications had stale dependencies? Which cloud workloads were unknown to the security team? Which compensating controls were improvised because the organization did not know what it ran? Those questions are uncomfortable because they are not limited to one CVE. They reveal structural weakness.

Inventory is not a static list. It changes as developers deploy new services, vendors update products, cloud workloads scale, containers are rebuilt, and old systems linger. A list that is accurate once a year will not survive a zero-day response. The control has to be live enough to answer urgent questions: where is this component, who owns it, what is exposed, what version runs, how do we update it, and how do we know the update worked?

SBOMs can help, but only if they are current, usable, and connected to operations. A PDF component list sitting in procurement files will not find an exposed server. A machine-readable SBOM tied to products, versions, vulnerability feeds, and owners can shorten the response. The accountability standard should be practical: did the inventory help teams find Log4j faster than manual searching alone? If not, it was not yet operational.

The public-service continuity angle was real

Log4Shell affected far more than private enterprise risk. Government services, public agencies, universities, health systems, and critical infrastructure operators all had to assess exposure. ENISA's Log4Shell vulnerability note and the UK NCSC's Apache Log4j vulnerabilities guidance show how national cyber authorities treated the issue as systemic. That was appropriate because the vulnerable component could sit inside systems citizens depend on.

Public-service continuity changes the accountability question. A government agency cannot treat repair only as internal cyber hygiene if public portals, benefits systems, emergency services, tax platforms, health services, or identity systems are potentially affected. Availability, integrity, and public trust matter. A rushed patch that breaks a service can harm users. A delayed patch can leave a service exposed. A vague public statement can undermine confidence. The repair needs evidence and coordination.

CISA's role in the United States was therefore not only technical. It helped create common expectations for covered agencies and a reference point for others. The directive, guidance, and resource hub gave agencies a structure for action. They also gave Congress, oversight bodies, and the public a way to ask whether agencies were following through. That is a governance function.

The same continuity problem appeared for private services with public dependence. Cloud providers, authentication providers, payment processors, managed-service providers, hospitals, and telecom-related platforms all had to preserve service while fixing exposure. Customers did not care whether the vulnerable component was buried three dependencies deep. They cared whether the service remained trustworthy and available.

Log4Shell thus blurred the line between vulnerability management and resilience. Repair teams had to patch without breaking production. Security teams had to mitigate without blocking legitimate traffic. Vendors had to issue advisories without causing panic. Executives had to allocate emergency resources. Communications teams had to avoid false certainty. Public authorities had to coordinate guidance across jurisdictions. This was not simply a software update. It was a continuity exercise.

Residual unknowns and the accountable question

The public will probably never know the full global repair record for Log4Shell. We do not know which organizations found every instance quickly, which left vulnerable products exposed, which were exploited but never discovered, or which vendor advisories were too late to prevent harm. We do not know how many internal-only systems were vulnerable but unreachable from attackers. We do not know how many old vulnerable components remained dormant until later.

Those unknowns do not make accountability impossible. They identify the evidence that matters. Who controlled software inventory? Who controlled product advisories? Who controlled emergency mitigation? Who controlled log retention? Who controlled vendor coordination? Who decided when a system was safe enough to return to normal operation? Who verified that a fix applied to the actual running component, not merely to a package list?

The answer was distributed. Apache controlled the project fixes and disclosure record for Log4j. CISA controlled federal emergency guidance within its scope and broader public coordination. Agencies and enterprises controlled their own inventory, mitigation, and monitoring. Vendors controlled product-specific advisories and patches. Cloud and security providers controlled defensive telemetry and customer guidance. Customers controlled their own follow-up questions and acceptance of residual risk.

No single actor could close the entire global risk. But each actor could provide better proof for the layer it controlled. That is the lasting accountability standard after Log4Shell. It is not enough to say "we patched." The public should ask: what did you find, what did you fix, what did you mitigate, what did you monitor, what did you miss, and how do you know?

From emergency to durable repair

The best Log4Shell lesson is not that organizations need to react faster next time, though they do. The better lesson is that emergency speed depends on ordinary preparation. You cannot invent an accurate asset inventory in the middle of a global zero-day. You cannot create vendor cooperation after contracts ignore evidence duties. You cannot hunt exploitation effectively if logs were never retained. You cannot verify remediation if owners, versions, and dependencies are unknown.

Durable repair should therefore change budgets and governance. Asset inventories should include component visibility. Procurement should require timely vulnerability disclosure and product-component evidence. Development teams should reduce dependency sprawl and update old libraries. Operations teams should test emergency patch and rollback procedures. Security teams should retain useful logs and maintain detection content. Executives should know which systems would be hardest to assess in the next systemic vulnerability.

This is where the proof problem becomes productive. Proof is not only for auditors. It tells the organization whether it can act. If a team can prove where a component runs, it can patch faster. If a vendor can prove which products are affected, customers can prioritize. If logs can prove no suspicious exploitation occurred in a defined window, leaders can make calmer decisions. If residual uncertainty is documented, risk owners can decide whether to add monitoring or compensating controls.

Log4Shell was frightening because it was everywhere and urgent. It was also clarifying. It showed that vulnerability response is a chain of evidence: project disclosure, vulnerability metadata, asset inventory, vendor advisories, patches, mitigations, exploitation monitoring, customer notice, and governance review. Break any link and the repair record weakens.

CISA's public role made that chain harder to ignore. By framing Log4Shell as an emergency requiring structured action and reporting for covered agencies, it helped move the conversation away from patch slogans and toward measurable repair. That is the standard the next systemic vulnerability should inherit.

Early explainers turned abstraction into operational risk

One reason Log4Shell spread so quickly through executive attention was that practitioners translated the vulnerability into plain operational consequences. LunaSec's early technical explainer, Log4Shell: RCE 0-day exploit found in log4j, helped many readers understand why logging untrusted input could become remote code execution in affected configurations. The point for accountability is not that every executive needed to understand every Java detail. It is that leaders needed to grasp why a routine component could turn ordinary request handling into a serious exposure.

That translation mattered because emergency response depends on management support. Security teams could not wait for normal maintenance windows if internet-facing systems were exposed. Procurement teams had to pressure vendors. Operations teams had to approve mitigations that might affect service behavior. Communications teams had to explain status under uncertainty. Finance teams had to support overtime, tooling, and emergency vendor engagement. Without a clear explanation of why the vulnerability mattered, repair could stall behind normal process.

The early public explainers also created a shared vocabulary for non-specialists. They showed why "we do not use Log4j directly" was not a sufficient answer. A product could use a framework, which used a library, which bundled a vulnerable version. A vendor might use it inside an appliance. An internal tool might have been deployed years earlier and forgotten. A logging path might receive user-controlled strings in ways application owners did not expect. That nested reality made discovery hard.

A mature organization should preserve that translation function for future systemic vulnerabilities. When a high-impact component flaw appears, the first briefing should separate mechanism, exposure path, affected asset classes, public exploit activity, available fixes, mitigations, monitoring, and open questions. Leaders should not be forced to choose between technical detail they cannot parse and vague urgency they cannot govern. Log4Shell showed that clear explanation is itself a control.

Exceptions were part of the risk record

Every large repair wave creates exceptions. Some systems cannot be patched immediately because a vendor has not released a fix. Some systems are fragile and require testing. Some are no longer supported. Some have operational owners who are unavailable. Some are isolated enough that compensating controls may be temporarily acceptable. Some are mission-critical and cannot be taken down without public harm. Exceptions are not automatically failures. Unmanaged exceptions are.

The Log4Shell repair record should therefore include exception governance. Which affected systems could not be patched by the target date? Why not? What compensating controls were applied? Who approved the delay? What evidence showed the compensating control worked? What date was assigned for final remediation? Who received escalation if the date slipped? A statement that "remaining systems are being remediated" is weaker than an exception register with owners and deadlines.

This is especially important for public-service environments. A system supporting citizen access may be too important to patch recklessly, but too important to leave exposed. The governance answer is not heroic improvisation. It is a documented risk decision that weighs exploit activity, exposure, available mitigations, service continuity, and recovery plan. The board, agency head, or executive risk owner should be able to see which exceptions remain and why.

Exceptions also reveal vendor dependency. If an organization cannot patch because a supplier has not issued a supported update, that fact belongs in procurement memory. The next contract should require faster advisories, clearer component disclosure, and emergency support. A supplier that repeatedly leaves customers unable to close critical vulnerabilities is not merely slow; it is shifting security risk to buyers who cannot repair the product themselves.

The best exception record is temporary. It should shrink over time, not become a permanent list of accepted exposure. After Log4Shell, organizations that still had affected systems months later needed to explain why: unsupported software, missing owner, business resistance, vendor failure, or genuine technical constraint. Each reason points to a different repair. Without that explanation, residual risk becomes normalized.

Rechecking mattered because the facts kept changing

Log4Shell response was not a one-day exercise. New affected products appeared. New vendor advisories were published. Additional Log4j vulnerabilities and fixed versions entered the public record. Detection content evolved. Scanners improved. Organizations that checked once and stopped risked missing later facts. This is why CISA's resource hub and directive model were important: the repair process had to remain alive as evidence changed.

Rechecking should be formal. A team should know when it last searched for affected assets, which source of vulnerability intelligence it used, which product advisories were reviewed, which scan results were confirmed, and which systems were retested after patching. If a new vendor advisory names a product the organization uses, the organization should not rely on the memory of a previous "all clear." It should reopen the item.

The same applies to build and deployment processes. A team might patch production but leave an old dependency in a source repository or container definition. The next build could reintroduce the vulnerable component. A team might patch one service branch but leave another branch behind. A developer might copy an old library into a new project. Repair evidence has to include prevention of reintroduction, not only emergency cleanup.

This is where vulnerability management connects with secure development. Dependency scanning, version pinning, artifact inventories, approved base images, and release review are not glamorous controls. They prevent the same vulnerability from resurfacing after a public emergency. An organization that cannot prevent reintroduction has not repaired the control environment; it has only survived the first wave.

Rechecking also matters for customer confidence. A vendor that updates its advisory as facts change may look less certain in the moment, but it is more trustworthy over time than a vendor that publishes a fixed statement and never revisits it. Customers know that systemic vulnerabilities evolve. They need vendors to say when facts changed and what that means. Silence after the first advisory can be misread as closure even when investigation continues.

Evidence should be retained for the next audit

The repair evidence created during Log4Shell should not disappear after the crisis. Logs, scan results, vendor advisories, patch tickets, exception approvals, customer notices, and executive briefings are useful months later. They help auditors assess whether the organization responded reasonably. They help incident responders understand whether later suspicious activity could trace back to the vulnerability window. They help procurement teams identify weak suppliers. They help engineers improve component inventory.

Retention is not the same as hoarding everything forever. The organization should preserve the evidence needed to reconstruct decisions. Which systems were affected? What action was taken? When was it taken? Who approved exceptions? What monitoring was performed? What customer or regulator communication occurred? What remained uncertain? That evidence should be stored in a way that survives staff turnover and emergency-tool sprawl.

The long-term audit should also compare expected capability with actual capability. Did the vulnerability database know where Log4j was? Did scans find what application owners found manually? Did vendor records map to real deployments? Did cloud inventories include all running workloads? Did logs support exploitation review? Did communication channels reach the right teams? Each gap should become a control-improvement item.

This turns Log4Shell from an isolated crisis into a rehearsal for the next one. The next systemic vulnerability may affect a different language, package manager, cloud service, authentication library, or hardware component. The specific patch will differ. The evidence chain will look familiar: identify exposure, coordinate suppliers, fix or mitigate, monitor for exploitation, manage exceptions, communicate scope, and prove closure. Organizations that retained and reviewed their Log4Shell evidence should be better prepared.

Customer questions should become contract language

Customers asked vendors urgent questions during Log4Shell: Are you affected? Which products? Which versions? What should we do? When will patches arrive? Have you seen exploitation? Will you notify us if facts change? Those questions should not vanish after the emergency. They should become contract and assurance requirements.

A stronger contract would require suppliers to maintain component inventories, provide vulnerability advisories within defined timeframes, publish affected-version matrices, support emergency mitigation, retain relevant logs, cooperate with customer evidence requests, and update notices when facts change. It would also clarify whether the supplier can provide SBOMs, whether the SBOMs are current, and how customers can consume them. The goal is not paperwork. The goal is faster repair when the next systemic flaw appears.

Supplier assurance should also test practice, not only policy. A vendor may claim to have vulnerability management, but customers should ask how quickly the vendor identified Log4j exposure, how advisories were issued, how exceptions were tracked, and what changed afterward. A vendor that cannot answer those questions may have survived the event through effort rather than control maturity.

The same lesson applies inward. Business units that buy software should not sign contracts that leave the security team blind during emergencies. Procurement should know which systems are critical, which vendors hold essential functions, and which contracts include evidence duties. Legal should support language that makes emergency cooperation mandatory. Executives should understand that cheap software can become expensive if the supplier cannot answer basic component questions during a crisis.

This is the accountability arc from Log4Shell: a vulnerability in a widely used component revealed weak inventories, weak supplier evidence, and weak exception governance. The repair is not only a fixed version. It is a better agreement about who must produce which facts when time is short.

The proof standard should be humane but firm

It would be unfair to pretend that every organization could immediately find every affected component in December 2021. The vulnerability was severe, the component was widespread, and public information evolved quickly. Many defenders worked under extreme pressure. Accountability should recognize that reality. It should not demand perfect omniscience.

But humane accountability is not soft accountability. It asks whether organizations improved once the gap was visible. Did they document uncertainty instead of hiding it? Did they prioritize exposed systems? Did they keep searching after the first wave? Did they communicate honestly with customers? Did they repair inventory, vendor, and logging weaknesses afterward? Did they make the next emergency easier?

This standard is fair because it focuses on control over time. A small organization may not have had a full component inventory on day one. It can still create a better one. A vendor may have needed time to test a patch. It can still publish interim mitigations and honest status. A public agency may have had legacy systems. It can still track exceptions and report risk. The measure is not whether every actor was perfect. It is whether each actor turned emergency discovery into durable improvement.

Log4Shell deserves to remain in the risk record for that reason. It is a reminder that the most dangerous phrase after a systemic vulnerability is not "we are investigating." That phrase can be honest. The dangerous phrase is "we patched" when no one can show what was found, what was missed, what was monitored, and what evidence supports closure.

The next systemic flaw will arrive under a different name. It may involve an identity library, a container image, a cloud control, or a package that feels too ordinary to be strategic. The accountable organization will be the one that can answer quickly because it already knows its components, owners, suppliers, logs, exceptions, and evidence duties. That is the real repair CISA's Log4Shell record points toward, and it is the measure worth carrying forward for resilience.

Typography

Typography originated with the invention of movable type by Johannes Gutenberg in the 15th century.
Key elements include font selection, kerning, tracking, and leading.
Good typography enhances readability and conveys mood or tone in design.