Red Sift's Guide to Certificate Lifecycle Management

Last update: 15 September 2025

In the past three decades, digital (X.509) certificates have gradually become part of critical infrastructure, with businesses relying on them to support essential business operations. And, yet, because the usage of digital certificates expanded gradually over time, many organizations haven't kept up with best practices; they continue to manage certificates in an ad-hoc fashion, without central oversight and control. These practices lead to an increase in business risks, unknown security exposures, as well as frequent outages.

This document is structured as follows: In part one, we will take a look at Certificate Lifecycle Management (CLM) tools and their capabilities. We discuss private and public PKIs, including their advantages and disadvantages. In part two, we outline a step-by-step CLM program that's applicable to organizations of all sizes. When followed, this program will enable you to take control of your digital certificate estate, taking you from the basics through visibility and control, and finally to automation and best security practices.

Certificate Lifecycle Management is a comprehensive process for managing digital certificates throughout their entire lifecycle. It's a critical aspect of cybersecurity that ensures an organization's digital identities and network communications are secure and trustworthy. A successful CLM program will satisfy two main requirements: 1) help discover and monitor organization's certificates and 2) provide operational support for certificate operations, including automation of issuance, deployment, rotation, and revocation.

Activities pertaining to certificate management are best viewed in the larger context of cryptography governance. Cryptography discovery and inventory are two related initiatives that are intertwined with certificate lifecycle management. CLM is best seen as a continuous program that's designed to satisfy organizational needs for availability, compliance, and security.

Certificate Lifecycle Management is a necessary function for most businesses, but there are currently two forces in play that require immediate action:

• Reduced certificate lifetimes: in the public PKI space, certificate lifetimes are being reduced from the current maximum of one year, first to 200 days in March 2026, then to 100 days in March 2027, and finally down to only 47 days in March 2029. Unless certificate renewal is automated, these changes are going to increase the direct operational costs related to the renewals as well as increase the likelihood of outages. Read more about these changes in our blog post on this topic.
• Post-quantum migration: the looming threat of a cryptographically-relevant quantum computer requires a migration away from public key algorithms that are in use today. The general consensus is that the migration of important properties needs to be completed in the next five years.

Public Key Infrastructure (PKI) is a system for management of digital identities. A digital identity is built from a private key, which forms the essence of an identity, and the corresponding certificate, which includes a corresponding public key alongside relevant metadata. The identities, alongside the rules for issuance, usage, revocation, and other similar operations, make up a PKI.

A PKI is usually created and designed for a particular need. In fact, it's a best practice to separate PKIs that don't have overlapping use cases, as that improves the security via compartmentalization.

Some PKIs are intended for cross-organizational collaboration, and we refer to them as public. If an organization creates PKIs for its own needs, we call them private. The key difference between the two is that, when it comes to public PKIs, there is usually a separate governance structure; the participants all have to follow the same rules. With private PKIs, organizations that create and use them have full control and can design them to meet their exact needs.

• Designed for cross-organizational collaboration and interoperability.
• Independent governance; everyone plays under the same rules.
• A lot of work is done by third parties, such as root programs and CAs.
• Changes are slow and may involve politics, waiting for the slowest to act, and so on.

• Designed for private organization use.
• Full control of the PKI design and operation.
• Requires more implementation effort to consider every aspect of the PKI.
• Can move at the speed of the organization.

There are several public PKIs we might be concerned with. Internet PKI refers to the global system that secures the internet. In it, digital certificates are issued to validate connections between network participants, typically using the Transport Layer Security (TLS) protocol. Web PKI can be thought of as a subset of Internet PKI, used only by browsers and adapted for their specific needs. The two PKIs overlap and the names are often used interchangeably. S/MIME PKI is designed to protect email communication and operates under separate rules.

These public PKIs are largely governed by the major root programs, such as the ones implemented by Apple, Chrome, Microsoft, and Mozilla. The root programs establish the rules and decide which CAs are able to participate. In addition, the CA/Browser Forum is an industry body that regulates some of the technical aspects of the public PKIs.

The key characteristics are the following:

• Anyone can participate
• Issuance based around proof of infrastructure control
• Short certificate lifetime effectively mandate automation
• Certificates are largely free
• All certificates are recorded in public logs
• Weak cryptography is not allowed
• Fixed certificate profiles
• Limited revocation checking options

The primary advantage of public PKIs is that they're managed by large global organizations, meaning the cost of participating is low or non-existent. This gives us inter-operability, but at the cost of flexibility. For many use cases, this tradeoff works well, especially now when public certificates are available free of charge. Even large organizations will often use public certificates for their private infrastructures.

However, there are some use cases where public PKIs prove too limiting:

• Lack of strong issuance authentication 
• No control over certificate lifetimes
• Certificates leak information about private infrastructure
• No support for client or device certificates
• No support for code and document signing
• No support for custom certificate profiles
• Rate-limited certificate issuance
• Limited options for issuance protocols
• Slower adoption of new standards (e.g., post-quantum cryptography)

Depending on the use case and the available expertise and budgets, an organization may choose to implement and host a PKI internally, or it could use one of the managed options offered by cloud providers and certification authorities.

We've established that certificates are created in their respective PKIs. Thanks to the now-widely available Automated Certificate Management Environment (ACME) protocol, individual servers can obtain their own certificates by directly communicating with their preferred CAs. This approach is used by small and large organizations equally.

Some organizations that want more control or more visibility may opt to use certificate lifetime management tools. For example, an organization that wanted to have visibility into their activities could deploy a CLM product that implements discovery and monitoring.

Larger organizations may rely on one or more CLM tools in order to enforce centralized issuance and have better control over which CAs are used where. This will be especially true if they operate private PKIs for their internal infrastructures. 

As with any other initiative, the key to launching a successful CLM program is to understand the underlying business needs. For example, consider the following security and compliance needs:

• Risk management and governance; provide visibility into all issued certificates to serve as a foundation for strong oversight and control.
• Regulatory requirements and compliance; ensure that the certificates comply with all relevant regulations.
• Improved security; monitor certificate deployments to ensure that sufficiently-strong cryptography is used.
• Cryptographic agility; support organization's ability to identify its cryptographic assets and quickly migrate to new cryptographic primitives when necessary. 
• Post-quantum cryptography migration; as an immediate and pressing need, support your organization's efforts to migrate away from vulnerable public key cryptography.
• Cost reduction and security ratings; reduce cost by ensuring the appropriate in-policy certifications are used. Additionally, improve the publicly-visible aspects of the organization's security posture, potentially leading to reduced cybersecurity insurance costs.

When it comes to the operational needs, there will be fewer requirements, but they require flawless execution because mistakes can lead to downtime:

• Automation: communicate with approved certification authorities (CAs) to have certificates issued, then deploy, rotate, and revoke certificates as needed.
• Availability and interoperability; ensure that the certificates are suitable for the intended audiences and satisfy the requirements for interoperability, performance, and resilience.
• Outage prevention and availability: minimize outages by monitoring deployed certificates for expiration, unexpected revocation, and other availability issues.

Given the complexities of PKI, it's not surprising that there is a variety of CLM and PKI tools, each designed to satisfy a particular use case, and no one tool that can do everything. The functionality usually falls into one of the following categories:

• Simple issuance automation; tools that automate issuance and renewal, usually running directly on the infrastructure that uses the certificates. Usually implemented via ACME and increasingly embedded in server software.
• Private PKI products; tools that create and manage private PKIs. They can be self-hosted or managed, often offered by large cloud providers and CAs.
• Discovery and visibility; tools that are concerned with building of certificate inventories and otherwise providing full visibility of all organization certificates, including how they're used and where.
• Lifecycle automation; tools designed for advanced orchestration of certificate issuance. Typically designed to integrate with multiple public or private PKIs. In order to support the advanced management options, these tools typically have plugins to integrate with a variety of platforms and server software.
• Certificate monitoring; some certificate monitoring is often included with tools that are primarily designed for network security and availability monitoring, or IT Operations management.

When deciding which tools to use, organizations should start with their objectives and questions, research the functionality offered by various vendors, and choose the tools that satisfy their needs.

With the increased popularity of ACME, more and more tools are becoming available to support certificate issuance and renewal. It's increasingly common to see ACME client functionality embedded in server software and appliances, making certificate management much easier. If not today, then pretty soon, most software that uses certificates will support ACME out of the box, making it easy to get basic certificate management capabilities.

This simple issuance automation may often be sufficient, but doesn't come with full lifecycle automation capabilities. Some operations, such as changing of the issuing CA or replacing certificates before they are due, may need to be done manually.

CLM products that implement full lifecycle automation may provide these capabilities out of the box. They may use ACME or their proprietary integration plugins. Thus, the choice is whether to go with simple automation and do some work manually should the need arise, or go with full automation and more work upfront, but less manual work later. If the full automation is preferred, special care should be taken to research if your CLM of choice supports integration with the platforms and software you're using. We recommend that you first start with a representative proof of concept before committing to a full deployment.

Finding the right tools to support your certificate lifecycle management program can be difficult, because they come with a variety of features and it's sometimes difficult to satisfy all needs with the same tool. When you're putting together your evaluation criteria, consider if the tools can provide answers to the following questions:

• Do we have an inventory of all our certificates?
• Are all certificates using strong cryptography?
• What CAs are being used?
• Are the right CAs used in the right places?
• Where on our networks are the certificates installed?
• Are the certificates and protocols deployed correctly and securely?
• Are we using post-quantum key exchange on important properties?
• Are certificates being issued and renewed automatically?
• Can we rotate certificates on demand?
• Can we handle an unexpected certificate revocation?
• Who and where is issuing our certificates?
• What third parties are issuing certificates on our behalf?
• Are there fraudulent certificates issued in our names?

In the second half of this document, we provide a step-by-step guide for a certificate lifecycle management program that will enable you to assert control over your public PKI estate. In essence, the entire problem domain of certificate lifecycle management and PKI boils down to three steps:

1. Establishing control of your public PKI estate
2. Management and evolution of private PKI deployments 
3. Deployment of one or more CLMs for full lifecycle automation

We built this programme on the observation that all organizations participate in the public PKI, but few have sufficient visibility and even fewer are in control of certificate issuance for their properties. At the same time, this aspect can be undertaken separately and completed quickly relative to the other tasks. As you take control of your public PKI, you will build valuable expertise that will help you understand your actual needs and inform your subsequent decision related to private PKIs and certificate automation.

In fact, the imminent reduction of certificate lifetime reductions to under one year virtually requires you to focus on your public certificates with urgency. With the first reduction to 200 days around the corner, in March 2026, you need to act fast or face substantial increases in the workload of manual renewal.

Start by enumerating your requirements and objectives. No two environments are the same, and this is especially true when it comes to PKI. We've covered a variety of common objectives in the first half of this guide. You should, at this point, evaluate each objective from the list and decide on its priority. This will help you establish the context to guide your decisions later on.

Additionally, industry trends and regulatory requirements will have a significant impact on what you choose to work on first. Take a look at the regulatory landscape to understand the compliance regulations. Cryptography has become a priority in recent years and is now on everybody's agenda. DORA, NIS2, NIST, FIPS, PCI DSS, HIPPA, and others have extensive requirements for how cryptography is used and how key management is implemented. The world is in the midst of a transition to post-quantum cryptography, with a lot of work and short deadlines; find out what you need to do and by when.

The advantage of Internet PKIs is that it makes it relatively easy to achieve full certificate visibility, compared to private PKIs. This is thanks to Certificate Transparency (CT), a system that's designed to collect and publish all public certificates for auditing and monitoring purposes. Technically, CT isn't mandatory, but, because Apple, Google, and Microsoft all require it to recognise certificates as valid, virtually all certificates are compliant.

With the right tool, full visibility of public certificates can be obtained essentially instantly, drawing from a complete database of all valid public certificates maintained by tool vendors. Starting from a list of organization-owned domain names, discovery from CT will sift through billions of certificates to find those that directly match the supplied domain names and any subdomains. Red Sift Certificates is our product that does this.

The ease of use of Certificate Transparency usually uncovers a different problem, which is that organizations tend not to have complete lists of their domain names. In many organizations we've worked with, such lists are compiled on demand, which is a process that takes significant effort and time.

To counter this problem, CLM tools can be augmented with other tools that are designed to discover an organization's infrastructure. This discovery capability is usually called Attack Surface Monitoring, or just ASM. Starting from a limited list of seed domains provided by the customer, and working off databases built from monitoring the entire world's infrastructure, products from this category will discover and maintain an up-to-date list of customer's resources. Integration with authoritative sources of information—such as domain registrars, DNS providers, and CAs—are used to ensure access to complete domain name inventories. We have incorporated automated infrastructure discovery into Red Sift Certificates for ease of use.

Desired outcomes:

• Comprehensive list of organization-owned registrable domains
• Automated syncing of the domain names from authoritative sources
• Continuous enumeration of all subdomains
• Continuous discovery of new registrable domains
• Comprehensive list of issued public certificates
• Reporting on issuing CAs and certificate problems

Having a complete inventory of certificates is a good start, but the real benefit comes from knowing how they're used and where. This step requires active network monitoring to determine the installed location and other information about every certificate.

• Domain and subdomain monitoring: working from the domain inventory, a monitoring tool continuously identifies and scans all relevant IP addresses for the given names. This type of monitoring will seamlessly take care of all public services.
• Firewall reconfiguration: some services may be running on publicly routable infrastructure, but without public access. Allowing access to the monitor tool at the firewall will provide more visibility with little effort.
• Monitoring of static network ranges: scanning of the network ranges that are known to be exclusively used by the organization can help discover domains that have slipped through or identify the services running on bare IP addresses. Ideally, this should be implemented via managed (agentless) scanning so as to not add to your workload.
• Private network monitoring: many organizations will have infrastructure that's not on public networks. The only visibility option in this case is to use agents with access to the private networks. This is usually the most time-consuming aspect of monitoring, as it requires installation of one agent per environment.

Desired outcomes:

• Discovery of all certificate deployments
• Enumeration of connected third-parties and their security postures
• Identification of first- and third-party certificates in risk of expiring
• Identification of incorrectly configured certificates
• Enumeration of available services, protocols, and cryptographic configuration
• Reporting on post-quantum migration coverage
• Reporting on automation deployment coverage
• Reporting on certificate sharing among services

At this point, you should have full visibility of all your certificates as well as their installed locations and related information. Unlike the first three steps, which always make sense in that sequence, from here you're more likely to work organically. For example, you may be able to immediately identify various critical problems, either related to expired certificates or to how they're configured and used. Presence or absence of post-quantum key exchange comes to mind as one aspect you may want to look into straight away. (We cover it in more detail later in this guide.) It makes sense to take care of these first, because the rest of your work will likely take much longer, as it will involve collaboration across departments.

The main goal of this step is to split your PKI estate into groups that make sense for your environment, usually based around business units, importance, and types of data they contain. Understanding your infrastructure at a sufficient level to perform the triage may involve a lot of communication across the organization.

After this, the next step is to identify the teams that will be responsible for each of the groups. This step is critical, as it will ensure that any detected problems are routed to the appropriate staff to deal with. As you do this you will identify third-parties that you rely on for service delivery. Depending on the nature of your relationship, you may or may not be able to treat them as one of the teams.

Once the groups and teams are established, enabling alerting should be a matter of flicking a switch. After this step, you hopefully won't see an expired certificate ever again.

This step is the foundation of all your future work, so take the time to identify all stakeholders and get them to participate in this program. Additionally, consider if it makes sense to connect your PKI tooling to your other tools, so that the certificate information is available where it's needed.

Desired outcomes:

• Identification of high-priority properties for urgent action
• Established business units and teams
• Grouping of properties based on priority and ownership
• Configured alerting to prevent future outages, routed to the right owners
• Identification of third-party services, embedded or delivered on your domains
• Integration of alerting with external systems via APIs

In 2025, automation is on everyone's mind, because the certificates that are still renewed manually—currently yearly—will have to be renewed twice a year after March 2026. That's because, at this milestone, certificates will be limited to a lifetime of 200 days. The reductions will continue, to 100 days in March 2027, and only 47 days in March 2029. Changes are you need to act quickly to find what isn't yet automated, then make sure your entire organisation acts to phase out manual renewals.

Support for automation via the Automatic Certificate Management Environment (ACME) protocol is growing every day, and it's soon going to be the default option for all certificates. The advantage of ACME is that it's generic, enabling you to switch to any CA that supports this protocol. Full lifecycle CLMs may provide custom integrations with more capabilities. They do, however, lock you in to the vendor. Going with ACME is the safer choice, and you can always upgrade to a proprietary CLM later on, possibly only for your high-value properties where you may need the additional capabilities.

You will need to decide on which CAs you wish to use, which is another decision that will depend on your circumstances. For public PKI, free CAs are likely to provide better value, as they provide essentially the same product at no cost. In fact, although free, Let's Encrypt is often the first to introduce new features and security capabilities. It's different when it comes to private PKIs, where you may need more support, tooling, as well as professional services.

Desired outcomes:

• Well-understood path to automation
• Enumeration of all environments that need certificates
• How-to documents to support automation in each environment
• Decision on when to use ACME versus proprietary CLM integrations
• A short list of trusted CAs that should be used

The advantage of the main public PKIs is that they have a built-in mechanism for activity monitoring and auditing, via Certificate Transparency (CT). We've already encountered CT in the first step, where it was crucial for our ability to quickly discover all certificates that belong to your PKI estate. In that case, our desire was to find all your certificates that have not expired. However, the same system can be used to discover your new certificates in real time, as they're created and recorded in the public CT logs. This is important, not only because you want to be able to see your certificates as soon as possible, but also because it helps you spot unauthorised issuances.

When it comes to the public PKI, domain owners don't have technical control over the issuance. Ultimately, any certification authority (CA) that's authorised to issue public certificates can issue for any domain name in the world, without needing the owner's consent. That's why having good monitoring in place is crucial in order to be able to detect fraudulent activity. 

Another aspect of CT is that it helps you understand your infrastructure. When a certificate is issued, it will contain one or more domains for which it is valid. This establishes a very effective discovery mechanism; you can discover new subdomains as soon as the associated certificate is observed.

Public certificates are recorded in CT logs, which are themselves available to anyone. With a good tool, inspecting what's being recorded in the logs is easy, especially if the tool also supports automation to help you make sense of large numbers of certificates and how they're used. If you wish, you can also look for open source tools that can help you to consume the same information directly.

Getting an email notification every time a new certificate is issued may initially be exciting, but it quickly wears off. To make it worse, what are you supposed to do with that information? And, how do you even distinguish between one of your certificates and a fraudulent issuance? That's a task perfect for competent automation.

CT monitoring tools tend to focus only on detecting certificates issued under known domains, but public PKI monitoring can be expanded to monitor all certificates for signs of fraudulent activity. This might make it possible to, for example, detect a certificate issued on a previously unknown domain name that's designed to look like one of yours, usually as a precursor for phishing activity. Detecting this sort of adversary is often implemented in a different type of tool, called domain and brand reputation protection. Red Sift's Brand Trust is one such tool.

Desired outcomes:

• Real-time monitoring of newly issued certificates
• Automated handling of routine issuance to suppress noise
• Identification of unusual issuances that require attention
• Identification of impersonated issuances across entire public PKI

One of the quirks of the public PKI is that issuance is not authenticated in the traditional sense. For ease of use, anyone can obtain a certificate when they prove control of the aspect of internet infrastructure they want the certificate for. While this works as intended most of the time, it also allows for certificate issuance when infrastructure is misconfigured. Take, for example, a type of problem called Dangling DNS, which occurs when a domain name is pointing to an IP address that's no longer under the control of the domain owner. This might happen, when you destroy a cloud server but forget to reconfigure the domain name that was pointing to it. Now, all of a sudden, a person who is assigned the same IP address can get a certificate with your domain name in it.

A relatively new standard called Certification Authority Authorization (CAA) is gaining momentum to introduce some order and provide control over certificate issuance. CAA enables domain owners to publish issuance policies that all CAs must respect. This still isn't strict authentication in the sense that the control ultimately lies with CAs, but it's the closest we can get to strong security with the public PKI as it is.

CAA policies are configured as DNS records under the domain names you wish to control. At the simplest level, they enable you to select one or more CAs you trust, implicitly forbidding all other public CAs from issuing. You can control issuance for regular and wildcard certificates, S/MIME, BIMI, and maybe other types in the future. When a single CA is allowed, further custom configuration can be communicated to further increase security.

CAA can be used in many different ways, but at a high level, consider the following situations: 1) by default, without CAA, any CA can issue for your properties; 2) a wide CAA with a longer list of CAs is easy to deploy yet reduces the attack surface significantly; and 3) a narrow and specially crafted CAA can be deployed to get best security when you need it. 

NOTE: In June 2025, the CA/Browser Forum voted to make DNSSEC checking mandatory for all DNS operations related to certificate issuance, and that includes CAA validation. From March 2026, having DNSSEC will ensure your CAA policies can be cryptographically validated, which will reduce the likelihood of successful attacks by those wishing to subvert them.

CT monitoring, which we covered in the previous step, works best with comprehensive CAA policies; in tandem, the two approaches can be very effective at filtering out everything that's not known to be a confirmed issuance.

Desired outcomes:

• Decide on a small list of trusted/competent CAs that are less likely to mess up issuance or be compromised
• Deploy your default wide CAA configuration to all domain names
• Deploy a deny-all CAA configuration on parked domain names
• Craft and deploy strict CAA configuration to high-value properties
• Deploy advanced CT monitoring that integrates with your CAA configuration

The world is in the middle of a transition to post-quantum cryptography, seeking safety from cryptographically-relevant quantum computers (CRQCs) that are thought to have powers to destroy the public key algorithms in widespread use today. Depending on the context, the transition may take five years for the most important properties, or ten for everything else. We don't know when the Q-Day, as it's sometimes called, may arrive, but we're hoping it won't come sooner than we're able to flee to safety.

When it comes to your public PKI, there is only one immediate action, and that is to improve the coverage of post-quantum key exchange across your properties. Even though we don't think anyone has access to a CRQC at the moment, there is a type of attack called "Store Now, Decrypt Later" (or "Harvest Now, Decrypt Later") where encrypted traffic is captured today, only to be decrypted at some point in the future when CRQCs become available. Depending on your threat model, this may require immediate action. If you need to preserve some information secret for another decade to come, and a CRQC arrives in the near future, it may already be too late.

We have prepared a separate detailed guide to help you with the transition to post-quantum cryptography.

Desired outcomes:

• Immediate action to deploy post-quantum key exchange to high-value properties
• Well-understood path for the rest of your estate

The last step on your journey to managing your public PKI estate is focused on a wide range of configuration issues that have the potential to erode your security. If you fail here, you may have your certificates under your full control, but does that really matter if they're not used correctly? Consider the following areas:

• Public key algorithm and strength: ensure that your certificates are using public key algorithms and key strengths that are adequate for their purpose. In the public PKI space, CAs will refuse to issue certificates for obviously weak keys, but some issues are still possible. This type of problem will be more prevalent in private PKIs.
• Cryptographic protocol configuration: ensure that only secure protocols are used, and that their configuration is adequate for the audiences. This configuration is not binary, as sometimes certain compromises are necessary to ensure interoperability with older user agents. 
• Certificate chain correctness: ensure that all certificates are deployed alongside a complete and valid chain that terminates with a root that's accepted by the intended audiences. The root itself need not be in the configuration. Misconfigured certificate chains have the potential to completely break certificates and are often difficult to troubleshoot.
• HTTP Strict Transport Security: deploy and preload HTTP Strict Transport Security (HSTS) on all domain names to ensure that invalid certificate warnings cannot be bypassed and that all plaintext traffic is automatically upgraded to encryption. HSTS is necessary to prevent users from clicking through warnings when they're under an active network attack.
• Secure HTTP cookies: ensure HTTP cookies are marked as secure and deploy Cookie Name Prefixes (RFC 6265bis) to address the historical weaknesses in how cookies are implemented in browsers. Lack of these features on an otherwise secure website may make it possible to hijack users' HTTP sessions.
• HTTP mixed content: ensure that your websites not only deliver the primary content encrypted, but that all embedded resources are also secure. All external links should also be encrypted.
• CAA policy: already covered in an earlier step and listed here for completeness; each property should be assigned an appropriate CAA configuration that restricts issuance.

Lean on your PKI tooling to help you determine which of your websites has these problems. Not all tools will support all of these standards. Most CLMs will help with PKI and TLS, but lack support for the security of the "last mile" configuration. We support all of these in Red Sift products. If you're currently using a tool that doesn't, consider using our free tool on hardenize.com to address the remaining gaps. Our free test may be useful if you need to collaborate with third-parties that don't necessarily have access to the same tools you do.

For more information, read our complete guide to SSL/TLS and PKI configuration, which provides detailed coverage of these topics and more.

Desired outcomes:

• Best practices guide for cryptography
• New systems deployed in line with the best practices
• A plan to bring existing properties in line with the best practices
• Governance plan for continuous policy evaluation and evolution