How EPDs Work for Concrete Products

Environmental Product Declarations (EPDs) for concrete are often treated as static documents—downloaded, cited, and compared as if the reported values are fixed properties of a material. In practice, a concrete EPD is the output of a structured modeling process that translates production and supply-chain data into quantified environmental impact results.

While the published EPD follows a standardized format, the results it reports are shaped by a series of technical choices made upstream: how products are defined, what data is collected, which background datasets are used, and how calculations are performed. These decisions do not invalidate EPDs, but they do limit how precisely results should be interpreted.

Understanding those limits is the difference between using EPDs as disclosure tools — and misusing them as precision instruments.

This article assumes familiarity with what an EPD is and how it is structured. For a foundational overview of EPD purpose, standards, and limitations, see What Is an Environmental Product Declaration (EPD)? Here, the focus is on how concrete EPD results are produced—and why compliant EPDs can still differ meaningfully from one another.

Overview of the Concrete EPD Development Process

At a high level, developing a concrete EPD follows a common workflow:

1. Defining the product scope and declared (functional) unit
2. Collecting and validating production and material data
3. Performing life cycle assessment (LCA) calculations under applicable rules
4. Compiling, verifying, and publishing the EPD

Each stage constrains the next. Choices made early in the process—particularly around scope definition, data sources, and assumptions—propagate through the calculations and directly influence the reported environmental impacts. The credibility and usefulness of a concrete EPD ultimately depend on data quality, representativeness, and disciplined application of the underlying rules.

Key Inputs and Assumptions That Shape Concrete EPD Results

The values reported in a concrete EPD are not intrinsic properties of a mix design. They are the result of a set of interdependent modeling choices related to product definition, system boundaries, and data sourcing.

Small differences in any of these inputs can propagate through the calculations and produce materially different results, even when EPDs are developed under the same standards.

The sections below focus on how these inputs influence reported environmental impacts—and why compliance alone does not guarantee comparability.

Product Scope and Declared (Functional) Unit

Every concrete EPD begins with a decision about what product is being represented. Depending on the approach, an EPD may describe a single mix design, a group of mixes with similar performance characteristics, or an averaged representation of production at a plant or across multiple plants.

Concrete EPDs report environmental impacts using a declared unit, most commonly one cubic meter of concrete meeting specified performance criteria such as compressive strength or exposure class. The declared unit defines the quantity of material being assessed and provides a consistent reference for reporting results.

A true functional unit would describe the service the concrete provides—for example, supporting a given load for a defined service life under specific exposure conditions. Capturing that level of functional performance would require project-specific design, durability modeling, and use-phase assumptions that fall outside the scope of a product-level concrete EPD.

The declared unit standardizes reporting, but it does not standardize performance outcomes.

Two concrete mixes can both meet the same strength class and exposure requirements while differing in cement content, SCM usage, aggregate sourcing, or production efficiency.

Just as mix designs vary to satisfy different structural, durability, cost, and supply constraints, concrete EPDs vary as well. When mix composition changes, differences in reported environmental impacts are not an anomaly—they are the expected result of declaring different products under a common reporting framework.

System Boundaries

System boundaries define which portions of the concrete life cycle are included in an EPD, and those boundaries vary by region and applicable product category rules.

In North American concrete EPD programs, cradle-to-gate boundaries are common, which cover impacts up until the concrete leaves the manufacturing facility. In European contexts, EPDs more frequently include additional life-cycle modules, such as transportation to site, construction, use-phase scenarios, or end-of-life stages.

Where cradle-to-gate boundaries are used, reported impacts typically cover raw material extraction, material processing, transportation to the concrete plant, and concrete production activities. Downstream stages—such as delivery to the jobsite, placement, curing, use-phase performance, and end-of-life treatment—are excluded.

These boundary choices are not discretionary. They are defined by regional PCRs to support consistency within a given program, but they also shape how EPD results can be interpreted. An EPD developed under one boundary definition does not represent the same portion of the life cycle as an EPD developed under another.

The consequence is not simply partial coverage, but constrained comparability. Results reflect only the life-cycle stages that were modeled and no more. Applying concrete EPD data beyond its defined system boundaries—particularly across regions or to draw conclusions about the environmental performance of an entire building—requires caution and, in many cases, additional analysis.

Primary Data from Concrete Production

Primary data reflects measured conditions at concrete production facilities and has a direct, outsized influence on EPD results. For concrete, this typically includes mix proportions, cement and supplementary cementitious material (SCM) quantities, aggregate usage, admixtures, plant energy consumption, and production volumes.

Because cement production dominates the global warming potential of concrete, relatively small changes in cement content, SCM substitution, or plant energy efficiency can produce noticeable differences in reported impacts. Primary data therefore anchors the EPD to a specific production context rather than an industry average.

Primary data does not eliminate uncertainty—it localizes it. A concrete EPD reflects the conditions it was built from: the mixes produced, the materials sourced, and the energy used at the time the data was collected. The credibility of the results depends on how representative, current, and consistently collected that data is across the declared scope.

Secondary Data, Background Databases, and Upstream EPDs

Not all processes contributing to a concrete EPD can be measured directly by the producer. Environmental impacts associated with cement manufacturing, aggregate extraction and processing, fuel production, electricity generation, and transportation are typically modeled using secondary data from background databases.

These datasets embed assumptions about technology, geography, and energy systems. While they are essential for completeness and comparability within a given program, they also introduce variability. Different background databases—or different versions of the same database—can yield different results for otherwise similar concrete products.

In some cases, secondary data can be refined through the use of upstream EPDs, such as EPDs for cement or supplementary materials. Where available and permitted by applicable PCRs, upstream EPDs can improve representativeness by replacing generic background data with supplier-specific, verified information. This can materially improve data quality, but it does not eliminate the need to understand underlying assumptions or system boundaries.

Differences between concrete EPDs may reflect not only mix design or plant operations, but also upstream modeling choices that are easy to overlook unless data sources are examined closely.

As a result, two concrete EPDs can differ meaningfully even when plant operations appear similar.

Transportation Assumptions and Regional Differences

Transportation modeling often sits at the boundary between primary assumptions and secondary datasets, which makes it especially influential—and easy to misinterpret.

Transportation assumptions are a significant—and often underestimated—driver of environmental impacts in concrete EPDs. These assumptions define where materials are sourced, how far they travel, the modes used (such as truck or rail), and the load efficiencies applied in the modeling.

For bulk materials like cement and aggregates, which are heavy and moved in large volumes, transportation impacts can meaningfully influence reported results. Small changes in assumed distances or sourcing locations can shift global warming potential, even when mix proportions and production practices remain unchanged.

Because transportation infrastructure, supplier networks, and sourcing patterns vary widely by region, concrete EPDs are inherently regional documents. An EPD developed for one geographic context does not necessarily represent the same logistical reality as an EPD developed elsewhere, even when the declared product appears similar on paper.

Understanding transportation assumptions is therefore essential when interpreting differences between concrete EPDs, particularly when comparisons cross regional, market, or program boundaries. Differences in reported impacts may reflect logistics and infrastructure—not changes in material formulation or production efficiency.

Differences attributed to “better” or “worse” concrete can sometimes reflect logistics, not formulation.

How Concrete EPD Calculations Are Governed and Validated

Calculation Methodology and Product Category Rules

Concrete EPD calculations are governed by product category rules (PCRs), which define how environmental impacts must be modeled and reported for a given product category. PCRs specify elements such as system boundaries, required impact categories, allocation methods, and allowable calculation approaches.

PCRs exist to establish a common, transparent framework for disclosure. By requiring that similar products be evaluated using the same methodological rules, PCRs make EPDs interpretable and usable across projects, programs, and markets.

That standardization necessarily limits methodological flexibility. Once a PCR is established, producers cannot selectively adjust system boundaries, impact categories, or calculation methods—even when alternative assumptions might better reflect specific production conditions. This constraint is intentional: it preserves consistency across declarations and reduces the risk that results can be shaped through selective modeling or boundary choices.

The implication is that concrete EPDs reflect compliance with a shared methodological framework rather than a customized optimization of environmental performance. This tradeoff—consistency over flexibility—is what allows EPDs to function as credible disclosure tools rather than bespoke analyses.

Role of EPD Software in the Workflow

In concrete EPD development, software is primarily a control mechanism, not an analytical authority. It enforces rules — it does not decide what those rules mean in context. Its role is to apply predefined calculation rules consistently once key inputs and assumptions have already been set.

EPD software enforces the structure defined by applicable PCRs: required impact categories, calculation sequences, and reporting formats. It helps manage plant- and mix-level data at scale and reduces transcription and arithmetic errors, particularly when EPDs are updated or reproduced over time.

What software does not do is resolve judgment-heavy decisions upstream. Product scope, data selection, background datasets, transportation assumptions, and representativeness are determined before calculations are executed. When those choices differ, compliant software outputs will differ as well.

As a result, EPD software improves repeatability within a defined methodological frame, but it cannot reconcile differences introduced by data quality, modeling assumptions, or regional context. Consistent software use does not imply comparable results unless those upstream choices are aligned.

Verification and Quality Assurance

Third-party verification is the final checkpoint in the concrete EPD development process. Its purpose is to confirm that the EPD was developed in accordance with the applicable PCR, that required rules were applied correctly, and that assumptions and data sources are disclosed as required.

Verification does not re-evaluate upstream choices. It does not reassess product scope, reconcile regional differences, or normalize results across EPDs. A verified EPD may still reflect conservative assumptions or region-specific conditions—as long as those choices comply with the rules and are transparently reported.

In practice, verification should be understood as a confirmation of procedural integrity, not analytical alignment. It ensures that the EPD is methodologically valid within its defined framework, but it does not make different EPDs equivalent, interchangeable, or directly comparable.

Interpreting and Applying Concrete EPD Results

Interpreting Concrete EPD Results

Concrete EPD results represent modeled averages produced under defined scopes, assumptions, and methodological constraints. Differences in reported global warming potential between EPDs often reflect differences in inputs and context rather than errors or noncompliance.

Variations in cement content, supplementary cementitious materials, transportation assumptions, electricity grid mixes, and data sources can all influence reported results. When these factors differ, divergence between EPDs is expected—even when declarations are developed under the same standards and verified through the same processes.

For this reason, small numerical differences should be interpreted cautiously. Comparisons that ignore differences in scope, data sources, or regional context risk overstating precision or drawing conclusions the underlying data cannot support.

Using Concrete EPDs Responsibly

Concrete EPDs are most effective when used as disclosure tools: to support transparency, reporting, and compliance within defined frameworks. They are not designed to predict project-specific environmental outcomes, substitute for whole-building analysis, or replace engineering judgment.

Responsible use of concrete EPDs means understanding how results were produced, what choices shaped them, and what questions they are—and are not—able to answer. When used with that context in mind, EPDs provide valuable environmental information without being asked to carry more interpretive weight than they were designed to bear.

EPDs are most useful when they inform questions — not when they are treated as answers.

‍