diff --git a/pep-0458.txt b/pep-0458.txt
index c7bc0065dc6..fd3a1c890bc 100644
--- a/pep-0458.txt
+++ b/pep-0458.txt
@@ -828,44 +828,26 @@ private cryptographic keys (belonging to any of the PyPI roles) are
 compromised.  The leftmost column lists the roles (or a combination of roles)
 that have been compromised, and the columns to its right show whether the
 compromised roles leave clients susceptible to malicious updates, a freeze
-attack, or metadata inconsistency attacks.
+attack, or metadata inconsistency attacks. Note that if the timestamp, snapshot,
+and bin-n roles are stored in the same online location, a compromise of one
+means they will all be compromised. Therefore the table considers these
+roles together. A version of this table that considers these roles separately
+is included in PEP 480 [26]_.
 
 +-----------------+-------------------+----------------+--------------------------------+
 | Role Compromise | Malicious Updates | Freeze Attack  | Metadata Inconsistency Attacks |
 +=================+===================+================+================================+
-| timestamp       | NO                | YES            | NO                             |
-|                 | snapshot and      | limited by     | snapshot needs to cooperate    |
-|                 | targets or any    | earliest root, |                                |
-|                 | of the bins need  | targets, or    |                                |
-|                 | to cooperate      | bin expiry     |                                |
-|                 |                   | time           |                                |
+| targets         | NO                                                                  |
+| **OR**          | timestamp and snapshot need to cooperate                            |
+| bins            |                                                                     |
 +-----------------+-------------------+----------------+--------------------------------+
-| snapshot        | NO                | NO             | NO                             |
-|                 | timestamp and     | timestamp      | timestamp needs to cooperate   |
-|                 | targets or any of | needs to       |                                |
-|                 | the bins need to  | cooperate      |                                |
-|                 | cooperate         |                |                                |
+| timestamp       | YES                                                                 |
+| **AND**         | limited by earliest root, targets, or bins metadata expiry time     |
+| snapshot        |                                                                     |
+| **AND**         |                                                                     |
+| bin-n           |                                                                     |
 +-----------------+-------------------+----------------+--------------------------------+
-| timestamp       | NO                | YES            | YES                            |
-| **AND**         | targets or any    | limited by     | limited by earliest root,      |
-| snapshot        | of the bins need  | earliest root, | targets, or bin metadata       |
-|                 | to cooperate      | targets, or    | expiry time                    |
-|                 |                   | bin metadata   |                                |
-|                 |                   | expiry time    |                                |
-+-----------------+-------------------+----------------+--------------------------------+
-| targets         | NO                | NOT APPLICABLE | NOT APPLICABLE                 |
-| **OR**          | timestamp and     | need timestamp | need timestamp and snapshot    |
-| bin             | snapshot need to  | and snapshot   |                                |
-|                 | cooperate         |                |                                |
-+-----------------+-------------------+----------------+--------------------------------+
-| timestamp       | YES               | YES            | YES                            |
-| **AND**         |                   | limited by     | limited by earliest root,      |
-| snapshot        |                   | earliest root, | targets, or bin metadata       |
-| **AND**         |                   | targets, or    | expiry time                    |
-| bin             |                   | bin metadata   |                                |
-|                 |                   | expiry time    |                                |
-+-----------------+-------------------+----------------+--------------------------------+
-| root            | YES               | YES            | YES                            |
+| root            | YES                                                                 |
 +-----------------+-------------------+----------------+--------------------------------+
 
 Table 1: Attacks possible by compromising certain combinations of role keys.
@@ -875,20 +857,25 @@ was susceptible to these attacks and how TUF could protect users against them
 
 __ https://mail.python.org/pipermail/distutils-sig/2013-September/022755.html
 
-Note that compromising *targets* or any delegated role (except for project
-targets metadata) does not immediately allow an attacker to serve malicious
+Note that compromising *targets* or *bins*
+does not immediately allow an attacker to serve malicious
 updates.  The attacker must also compromise the *timestamp* and *snapshot*
 roles, which are both online and therefore more likely to be compromised.
 This means that, in order to launch any attack, one must not only be able to
 act as a man-in-the-middle, but also compromise the *timestamp* key (or
 compromise the *root* keys and sign a new *timestamp* key).  To launch any
 attack other than a freeze attack, one must also compromise the *snapshot* key.
-
-Finally, a compromise of the PyPI infrastructure MAY introduce malicious
-updates to *bins* projects because the keys for these roles are online.  The
-maximum security model discussed in PEP 480 [26]_ addresses this issue and goes
-into more detail about generating developer keys and signing uploaded
-distributions.
+In practice, this PEP recommends storing the *snapshot*, *timestamp*, and
+*bin-n* keys together, or even using the same key for all of these roles.
+Because of this, the attacker only needs to compromise this single server to
+perform any of the attacks listed above. Note that clients are still protected
+against compromises of non-signing infrastructure such as CDNs or mirrors.
+Moreover, the offline *root* key will
+allow the repository to recover from an attack by revoking the online key(s).
+
+The maximum security model shows how TUF mitigates online key compromises by
+introducing additional roles for end-to-signing. Details about how to generate
+developer keys and sign upload distributions are provided in PEP 480 [26]_.
 
 
 In the Event of a Key Compromise